[data.search.aggs] Use point in time searches for "Other" bucket

[wylieconlon]

The point in time API would prevent potential edge cases in the "Other" bucket by executing sequential requests using the same context. This would be especially useful for handling slow queries with updates happening in between, a situation that can cause inaccurate results today.

It is likely that we would need to implement this as part of the search strategies repository, so that the fallback case when the point in time API is not available is to run searches normally.

cc @lizozom @lukasolson

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[lukasolson]

I'm curious if we have any idea of the performance impact creating a PIT has on a search request. Do we have any data comparing two serial requests without PIT to the same using PIT? Or even creating the PIT itself?

[wylieconlon]

That question would best be answered by @dnhatn or @jimczi

[dnhatn]

@wylieconlon @lukasolson Thank you for working on it.

I'm curious if we have any idea of the performance impact creating a PIT has on a search request.

A point in time is created in a separate step, and that step should be fast.

Do we have any data comparing two serial requests without PIT to the same using PIT?

The overhead of PIT in a search is trivial. We don't expect any performance impact with PIT. If any, then we will address it.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[lukasolson]

Somewhat related: #88480