[Reporting/CSV Export] Use points-in-time for paging through search responses

[tsullivan]

Points in Time

Goal: Reporting CSV Export uses _scroll as the search API in Elasticsearch for paging through the results.If the hits are sorted based on unique value(s), using Points-In-Time would be more optimal than using _scroll.

Challenge: paging through search responses using the point-in-time depends on having unique values for the sort keys, which is something the user might not be concerned with when creating a view in Discover. There is no way for Reporting to know if the search responses will have duplicate sort keys.

Here are some success scenarios where using PIT would be best:

1. Works by default:
   • The user has a view in Discover where the hits are sorted based on their "time field", which has unique values
   • Each sort key is unique, as no records that have the same timestamp.
2. Works by explicit user action:
   • The user has a view in Discover where the hits are sorted based on their "time field", which aren't unique
   • They click a 2nd field to sort by, which is unique per-timestamp in its values
   • Each sort key is unique, as no records have the same combination of timestamp-and-other-field.

To solve the goal, Reporting needs a way to know if the request fits a success scenario for PIT.

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[lukasolson]

Related: #80406

[tsullivan]

I'm closing this issue for now, as there doesn't seem to be a way to reliable know when we can use PIT for search vs scan-and-scroll, since the data source is the user's. We can always re-open this issue if a way forward appears.