[TSVB] Old request might override newer request_handler

[alexwizp]

Fix: #14208

Summary

Description of the problem including expected versus actual behavior:
TSVB doesn't abort old queries when new ones are created

Steps to reproduce:

1. Create a new TSVB time-series visualization
2. Run a long query (over a long time range)
3. While the previous query is still running, update the time range to smaller range
4. The new query will finish before the first one, and update the visualization, and then the old query will finish and override the visualization, even though it was basically "aborted"

Also you can reproduce this issue using Network Throttling Profile:

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• 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
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

Pinging @elastic/kibana-app

[markov00]

Hey @elastic/kibana-app-arch can somebody review this PR because it includes a change to the vis loader. In particular, Alex is adding an visInstanceId to the VisualizeLoaderParams, this is used to have a unique ID of the instantiated visualization on a dashboard so that they can abort an old fetch call if a subsequent request is made. The ID is needed because we can have multiple instances of the same visualization on a single dashboard.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[ppisljar]

I see a few problems with this implementation:

• solves issue for tsvb only, seems as a general problem with our infrastructure which will affect everything
• we shouldn't need visInstanceId, each panel on dashboard has its own instance of visualize_embeddable_handler, which should take care of canceling old request
• having visInstanceId as parameter, what happens when we give users ability to type query (like in canvas) ? having to type this in doesn't seem optimal.

i think a better approach would be to solve this on the embedded_visualize_handler level:

• in update, see if previous fetch/render is still in progress and cancel it.

For now fetch execution wouldn't be canceled, but we would just ignore the old request, as courier doesn't support query cancellation at this point, nor does interpreter. But this would work well with our plans for the future:

• with @timroes we discussed a while back that we will need a general way to cancel interpreter expression execution, where every function could provide a cancel method.
• lucas is working on courier and adding query canceling support

[lukeelmers]

I agree with @ppisljar's comments here; since this is a more general problem we shouldn't do something TSVB-specific.

The issue is also already captured in #24058 -- I'm wondering if we should just close #14208 as a duplicate.

[alexwizp]

@lukeelmers @ppisljar I'll close this PR and will wait for common solution