[Console] Fix the end range of selected requests

[yuliacech]

Summary

Fixes #189366
Fixes #186773

This PR refactors how the request body is being extracted from the editor to use for "sendRequest" and "copyAsCurl" functions. Previously the editor actions provider would rely on the parser to get a JSON object or several for request body. The downside of this implementation was when the parser would not be able to fully process the json object. That could lead to potential text loss and the editor would process the requests in a way that was not always obvious to the user. For example, the editor would highlight the request with the json object, but when sending it to ES the request body would be completely ignored.
Instead this PR suggests to use the "raw" text from the editor for actions and give the user more transparency and control over the requests. We also don't need to keep the information about requests in the parser, which might affect browser performance for longer texts.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Flaky Test Runner was used on any tests changed
• Any UI touched in this PR is usable by keyboard only (learn more about keyboard accessibility)
• Any UI touched in this PR does not create any new axe failures (run axe in browser: FF, Chrome)
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Multiple Spaces—unexpected behavior in non-default Kibana Space.	Low	High	Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces.
Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks.	High	Low	Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure.
Code should gracefully handle cases when feature X or plugin Y are disabled.	Medium	High	Unit tests will verify that any feature flag or plugin combination still results in our service operational.
See more potential risk examples

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[yuliacech]

/ci

[elasticmachine]

Pinging @elastic/kibana-management (Team:Kibana Management)

[ElenaStoeva]

Thanks for working on this @yuliacech! Tested locally and most of the incorrect behaviours from the mentioned issues seem to be fixed now! I do still notice an issue with incorrect request selection though - when a request is invalid, the next request below (which is valid) is included in the selection, and it's not possible to only select the valid request. I wonder whether there might be a fix for this that doesn't require too much effort, wdyt?

Screen.Recording.2024-08-15.at.14.36.50.mov

[yuliacech]

Thanks a lot for the review, @ElenaStoeva!
That is currently no straight forward way to recognize any valid requests after an invalid one, because we rely on the parser for a request start. With an invalid request, the parser is still trying to parse the previous invalid request and gets stuck on it. I'll open a follow up issue for this, we should look for a way to force a "restart" on the parser somehow.

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 440345a

Failed CI Steps

• FTR Configs #73

Test Failures

• [job] [logs] FTR Configs #73 / Cloud Security Posture Test adding Cloud Security Posture Integrations CSPM AZURE Azure Organization Manual Service Principle with Client Secret Azure Organization Manual Service Principle with Client Secret Workflow

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/monaco	123	120	-3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
console	460.9KB	461.9KB	+1.1KB

Unknown metric groups

API count

id	before	after	diff
@kbn/monaco	123	120	-3

History

• 💚 Build #228169 succeeded 2bb139c
• 💚 Build #227601 succeeded efcf4c0
• 💚 Build #227308 succeeded 90c3be0
• 💚 Build #227251 succeeded 90c3be0
• 💔 Build #227148 failed 77803b7
• 💛 Build #227101 was flaky 2cbffbf

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

[ElenaStoeva]

Thanks for clarifying @yuliacech, this makes sense! Changes lgtm.