Expose state container for global data updates from data plugin

[Dosant]

Looks like we will have to add this to data plugin as part of the api. Because with current setup, if to apply this for multiple apps: each app will create a state container, which will all the time independently orchestrate data.query changes.
So we should add 1 state container on a data plugin, which apps could reuse and receive the updates.

cc @lizozom, I think you've mentioned something like this

Originally posted by @Dosant in #55818

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[lukeelmers]

What do you mean by "Expose state container for global data updates"? I read up on the other PR, but for some reason I'm not following.

Do you mean we'd provide a state container specifically for query service in the data plugin, which other apps can use to read/write query updates?

Or do you mean there's some sort of "global shared state" container with multiple items in it?

[Dosant]

@lukeelmers, maybe this could give more context: #55818 (comment)

In the #55818 we have to "watch" for any update coming from either global filters, time range or refresh interval and then update _g urls in navbar with that information.

In legacy it was done in one place in chrome and chrome updated all the urls in navbar. But in np, it was decided that apps "watch" for those updates themselves and update their own url in navbar.

With current setup as in #55818, an app creates a state container which orchestrates changes from "global filters, time range or refresh interval". And each app have to orchestrate it. These orchestration is happening when apps are not mounted (see the setup phase of dashboard plugin).

These issue I created is for fixing the performance problem of doing redundant orchestration per each app. Instead we can do it once, by either exposing change$ observable on data.query or at least add memoize to getSyncQueryContainare which is used in that pr.

[lukeelmers]

Ah, that makes more sense. I didn't grok that from the other PR; appreciate the follow up explanation!

[lizozom]

This however does contradict what we discussed with @ppisljar about the responsibilities of applications vs. services managing state.

I'm not staying I have a strong opinion either way ATM, but that we should brainstorm on the technical level and reach a conclusion we all stand by.

[Dosant]

This one can be closed, as #57168 covers it.
Pr #56128 covers immediate sub url tracking issues