fields which are only used for filtering should be moved out of the `query` section of the mapping

[harrisonpim]

We currently have four top-level objects in our mapping

• display: the document we show in the api, not indexed
• debug: for developers' eyes only, nothing indexed apart from indexedTime
• query: the mashed up, heavily analysed fields which are all indexed and used to control relevance, with some keyword subfields used for filtering
• aggregatableValues: which are used for aggregations, also indexed as keywords

There's a chance that we're indexing too many fields in the query section - devs working filters assume fields are there for relevance, and those engineering relevance assume they're there for filtering. The end result is a bloated index with unused fields, or fields serving multiple purposes which are hard to disentangle.

We could be more explicit about the separation of filtering and relevance-scoring by splitting the top level into

• display: as above
• debug: as above
• query: only used for relevance scoring

• filters: which might be structured like

  {
  "filters": {
    "fieldName": {
      "filterableValues": ___,
      "aggregatableValues": ___
    }[]
  }
  }

  in which all indexed fields should be keywords or dates

[agnesgaroux]

Has this been completed?