simplify mvt end point

[iverase]

This change unifies the mvt end point into one unique call.

GET /{my-spatial-index}/_mvt/{field}/{z}/{x}/{y}

The rest interface allow a body with the following optional parameters:

{
  // Like an Elasticsearch query
  "size" : 1000                             -- max number of features
  "fields" : [...],                         -- fields to be added to the hits layer
  "runtime_fields" : {...},                 -- runtime fields if any
  "query" : {...},                          -- filter conditions
  "aggs" : {...}                            -- metrics to add to the aggs layer
  // Specific to vector tiles
  "extent" : 4096,                          -- extent of the tile
  "grid_view" : "grid",                     -- cluster or grid   
  "grid_precision" : 8,                     -- values from 1 to 8
  "exact_bounds" : true                     -- should compute exact bounds
}

The generated vector tile will contain up to three layers:

meta layer: Always generated, it contains
hits layer: One feature per matched document. If size is equal to 0, the layer is not generated.
aggs layer: Each feature represents a buckets on a geo tile aggregation. if grid_precision s equal to 0, the layer is not generated.

[elasticmachine]

Pinging @elastic/es-analytics-geo (Team:Analytics)

[imotov]

LGTM. Do you anticipate having more different endpoints in the future or we will try to expand this endpoint to accommodate future needs. I am just wondering if we should bite the bullet and get rid of abstract middle class now. It might still make sense to keep the rest logic and the rest of it separated into different classes, but I wonder if we should make the "logic" class more service-like.

[iverase]

I have thought about that a bit. I had tried to place in the abstract class all the parameters that are shared with a standard Elasticsearch query and in the concrete class add the parameters that manipulate the vector tile format. The idea is that the abstract class parses and generates the query and the concrete class just serialise the result. We might think in having different serialisations?

I found there was not a clear cut so I am tempted to remove the abstract class.