Patterns: Use runtime datasource for queries

[gtk-grafana]

Refactoring the patterns call to use runtime datasource.

Fixes: #670

This is a pretty big refactor, but the end goal should be that we don't re-query the patterns on every route change, just when:

1. You change the time range
2. You change a label (but we get 2 queries one before the route change and one after, the first one gets cancelled, this is acceptable for now, but we should do UX: Don't automatically switch tabs when filters change #640 next, and then follow up with adding the detected_labels to runtime datasource and clean up any remaining hacks to stop duplicate queries on route changes)
3. You view the patterns route (for the first time, or 10% of time range has elapsed)
4. The first time you view a route with a particular service selected

Ok, I've tried a few different approaches with this, and while this "requires" (not really required, but it would be good to avoid the hack to call a private method) a scenes core change (grafana/scenes#866), I think this is the cleanest approach so far.

Some history: Initially I saw that the special $data provider didn't allow multiple query runners, but did allow multiple queries, so I tried stuffing the patterns resource query in with the typical data api call. But this broke a bunch of assumptions that scenes has about the data being returned by a query runner, primarily we had multiple queries that called different api endpoints, so the results would come in at different times. I could work around this by holding the "done" state until all queries had resolved, but then if you had one query taking longer then the other, you'd either need to change the assumption that you wait for a query state to be "done" before doing stuff with the response, but this would cause unnecessary re-rendering in panelBuilders that directly consumed data providers, as sometimes the dataframes would be undefined when it was actually loading.
Anyway, that was a terrible idea.

So instead of trying to use $data, in this current attempt we're just adding more custom data providers to the state of the ServiceScene $patternsData. This works much better, but if I activated the query provider in the serviceScene we'd still get unnecessary executions of the patterns call, for example on every route change. But we just want to run the patterns call on specific route activations, or when the time range changes, or the labels variable has been updated, or the user is entering the application for the first time. But we can't move the data provider down the scene tree as we expose the count of the patterns in the tabs which are visible across all routes.

So currently we're never activating the patternsData query runner, but we call runQueries in the specific cases where we want it to update. This works fine except we need to extend the SceneQueryRunner class and prevent runQueries from calling subscribeToTimeRangeChanges, as this will make the exact same request twice (but only the first time a scene is activated).

This should give us the desired functionality to only request the patterns when we need it, instead of on every route change that has ServiceScene as a parent (which is the entire application, except the service selection scene), and still take advantage of query caching caching within scenes.

[gtk-grafana]

We don't need multiple queries anymore, and I would highly suggest we don't mix queries that call different API endpoints, but if we wanted to include multiple queries that call the same API endpoint this should work.

[matyax]

At first glance, I like this ability of running more than one query. What was the original purpose of this change?

[gtk-grafana]

Initially I tried to smoosh all the queries into $data, which was a bad idea as queries would end at different times, but if we have multiple data queries, that should work fine as they are all returned from the backend at the same time

[svennergr]

I think it makes sense for "combined panels", i.e. the ones at the service selection scene, where we do one logs and one metrics query for each service 👍

[gtk-grafana]

Good point, that's probably worth opening in another issue. Might be good for the lazy-loaded panels as well to at least batch things up a bit.

[matyax]

I haven't tested this yet, so I plan to do a more in-depth review tomorrow, but took a good look at the changes and didn't find anything that stands out, aka, looks pretty good 👌

[svennergr]

Looking great, works very good. Left a couple of comments, but nothing too big. Good job!

[svennergr]

I think it makes sense for "combined panels", i.e. the ones at the service selection scene, where we do one logs and one metrics query for each service 👍

[matyax]

So far it works very well, but I found this case where the query is not re-run after removing the last filter. Can consistently reproduce with any field.

Test.mov

[matyax]

I can no longer reproduce ☝️

[matyax]

To the moon 🚀

[svennergr]

LGTM