ValuesSource support for reading points

[nik9000]

There are a few aggregations where we could really use some kind of clean way to get access to the "points" because we can iterate those in sorted order for the whole shard. Specifically composite, min, max, date_histogram and auto_date_histogram look at the points. We'd love to have some nice way for them to do it that tells folks when they implement a new type that this is something that they should think about.

min and max look up the minimum or maximum value and cast it to a double. date_histogram and, soon, auto_date_histogram look up the minimum and maximum dates so they can deal with rounding more efficiently. composite iterates values is sorted order.

[elasticmachine]

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

[iverase]

There is an idea to use points to compute bounding box aggregation for geo data (points and shapes are just multi-dimensional points). It would be good if the abstraction can hold the concept of dimensionality?

[nik9000]

I think it'd need to be a fairly thin abstraction. One common need is preflight checks to make sure that the points are "valid". Like, "there isn't a script on this field" and "there isn't a missing value" and "we're indexing this field at all".

Part of my problem is I'm not sure what the right shape for the abstraction should be. It certainly should support date's resolution but how to line that up with everything else, I dunno.

[polyfractal]

To add another data point, there's an old (stale) PR to add BKD optimization to range agg: #47712. We put it on hold because we wanted to investigate a similar optimization for date_histo, which would have a far greater impact.

It might not fit with the above abstraction since it would be fairly more involved. Not just getting a min/max, but building multiple ranges to intersect. That said it would share a lot of the same upfront initialization stuff (preflight checks, getting the point reader, etc)

[nik9000]

I'd be happy to add something for this as sort of a follow-up to #55559.