This PR tries to reduce the Elasticsearch cluster load for index patterns with many indices.
**Theory of operation**
Before this PR, Elasticsearch had to perform the query and sorting for every shard matching the index pattern. In order to avoid that in a time-base indexing scheme, the queries should include a `range` filter. This enables Elasticsearch to rewrite most of the shard accesses to `match_none`. But since the context view operates on document counts, the time intervals need to be determined heuristically:
* start of the interval is the second end of the previous query iteration or `anchor_time` if it is the first iteration
* end of the interval is `interval_start +/- n days` with `n in {1, 7, 30, 365, 10000}` or unlimited if insufficient hits were returned for all `n`
This date arithmetic introduces the assumption that the primary sorting field is a date or at least numeric. Therefore, the `sortingField` has been renamed to `timeField` to make those new assumptions explicit.
**Other notes**
As an additional optimization, the queries are now executed in a `constant_score` filter context to enable caching by Elasticsearch.
Tests for `fetchSuccessors` and `fetchPredecessors` were added.
Changes in ElasticSearch required a concurrent fix of #17696, which is also included. It now splits up the anchor `uid` into `anchorType` and `anchorId` and uses them in an `ids` query.
**Testing**
The fact that only a small subset of the shards are involved in a query should be observable using the `skipped` shard count in the response.
fixes#15143fixes#17696
cf16b801fd