[Reporting] fix too_long_frame_exception by passing scroll_id in the request body

[tsullivan]

Summary

Fixes #102971

An HTTP line can not be longer than 4096 bytes. This becomes a problem when using scan and scroll with Elasticsearch, and having the scroll ID placed in the path of the URL.

Bad:

GET /_search/scroll/really_really_long_scroll_id?scroll=30s
DELETE /_search/scroll/really_really_long_scroll_id

When the URL is too long, Elasticsearch may respond with an error:

[too_long_frame_exception]: An HTTP line is larger than 4096 bytes. 

The scroll ID should be in the POST payload body.

Good:

POST /_search/scroll
{"scroll":"30s","scroll_id":["really_really_long_scroll_id"]}
DELETE /_search/scroll
{"scroll_id":["really_really_long_scroll_id"]}

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

Release note

Fixed an issue with CSV export that could limit the size of the export to 500 lines.

[tsullivan]

@elasticmachine merge upstream

[elasticmachine]

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

[elasticmachine]

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

[spalger]

@elasticmachine merge upstream

Sorry @tsullivan, the cloud instance behind ci-stats had a little fit so that build wasn't going to succeed due to metrics at least, so I started it over.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 359e69a
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💚 Build #135370 succeeded 13c9f33
• 💚 Build #133276 succeeded 618a760

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[jloleysens]

Great job finding this @tsullivan ! I had no idea that scroll ids were that big potentially.