[Sessions] Extract search abort controllers logic into a separate class

[lizozom]

Summary

Extract search abort controllers logic from the search interceptors into a separate class.

Needed for #92439 as it requires merging abort signals of multiple instances of cached requests.

Explanation

Aborting a cached search$ will now potentially depend on multiple abort signals (As described in #92439 (comment)).

To handle that, we will store the SearchAbortController in the cache, alongside the observable.

When a response will be returned from cache, we will use the addAbortSignal to make sure we abort the underlying search only when all consumers abort it.

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
• 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

For maintainers

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

[elasticmachine]

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

[lukasolson]

This approach makes sense to me... So in the search interceptor, if we get a cached observable, then we'd just addAbortSignal and return?

[lukasolson]

Nit: So you don't have to do line 23

Suggested change

	private abortHandler() {
	private abortHandler = () => {

[lizozom]

I didn't understand this comment

[Dosant]

Lukas pointed this out to avoid:
this.boundAbortHandler = this.abortHandler.bind(this);

[lizozom]

Thanks!

[Dosant]

LGTM

Needed for #92439 as it requires merging abort signals of multiple instances of cached requests.

Could you elaborate, please? Maybe a short sample how it will be used will be helpful?

Will we store a searchAbortController instance as part of a cache?

[Dosant]

looks good.
tested cancelations using Discover and Dashboard using slow network and shard delay
Didn't notice any user-facing changes

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 5097a6e
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
dataEnhanced	97	98	+1

Async chunks

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

id	before	after	diff
data	202.8KB	202.8KB	-1.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
data	804.1KB	802.8KB	-1.3KB
dataEnhanced	23.9KB	25.4KB	+1.5KB
kibanaUtils	144.1KB	143.1KB	-1010.0B
total			-836.0B

History

• 💚 Build #116088 succeeded ed1f6f0
• 💔 Build #116072 failed 765c942
• 💔 Build #115901 failed 9554535
• 💔 Build #115894 failed e1574dc

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

cc @lizozom

[kibanamachine]

💚 Backport successful

✅ 7.x / #95779

This backport PR will be merged automatically after passing CI.