[Reporting] Improve deep pagination method for CSV export

[tsullivan]

CSV export uses the scroll API to paginate through all the data for a user's search. This has considerable expense internally in Elasticsearch, especially when the search spans a large number of shards.

Alternatives:

1. Async search can be used to search a large amount of data over a large amount of shards.
   • Negative: Elasticsearch doesn't allow to store an async search response larger than 10Mb
2. Point-in-time can be used to page through search hits when there are more than 10,000. There's no limit to the number of shards for backing the data. Elasticsearch adds an automatic tiebreaker to the sort results when PIT is used, so the search_after will not skip over documents.

Requirements:

• Testing needs to be put in place where CSV export is pulling data from a search with 500+ shards.
• Include shard failure warnings in the job output. See [Reporting] The CSV exporter should inform users of when there are too many scroll contexts open #142824
• No breaking changes to the xpack.reporting.csv.scroll settings: try to leverage those settings where possible.
• No changes needed to the Cloud settings allowlist

[elasticmachine]

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

[tsullivan]

The goal is to use the Point-in-time API.

1. When the data is time-based, the user's timestamp field will be used as the sort key for sort_after. In case there are duplicate timestamps in their data, we must add another sort field to be the tiebreaker. I'll try to use the document _id as the tie breaker.
2. When the data is not time-based, the data will be sorted by _id.

[tsullivan]

related #88303