AdhocFilters: Improve typing and signature of getTagKeys and getTagValues and behaviors

[torkelo]

Started working on adhoc filters for scenes and want to review and try to improve the system.

Goals

• Enable adhoc filters to take into account existing added filters when suggesting keys and values
• Enable adhoc filters to support a list of "baseFilters" that are not shown in the UI but used to filter down keys and values.
• Enable data sources to get adhocFilters to apply to a query without having to call templateSrv.getAdhocFilters(this.name); (not in this PR)
• Improve / add missing types

Changes

• Add typing to getTagValues options argument
• Add typing to getTagKeys options argument
• Make options argument take in existing filters so that ad-hoc filters can take those into account when returning keys and values
• Implement support for taking existing filters into account for Prometheus
• Update AdhocFilter picker/builder so that it passes existing filters to getTagKeys and getTagValues
• InfluxDB was also passing options arg to getTagKeys, with a very strange/incorrect typing (InfluxQuery).
• Add some foundational support for "baseFilters", filters that are not visible in the filters UI but are taken into account when fetching filter keys and values. This replaces the custom Prometheus getTagKeys solution of passing in the series array.
• Need help testing Tempo adhoc filter bit

The tempo => adhoc filters => Prometheus thing

To support adhoc filters in the tempo query builder a series[] name array was added to getTagKeys to filter tag keys by some series names. This is too specific to Prometheus. The getTagKeys and getTagValues need to be more generic. So changing this work with the new way of passing in existing filters / baseFilters. Prometheus can filter on multiple series names using regex label matching.

Adding adhocFilters to DataQueryRequest

The PR actually only started with this change, but then noticed the poor typing and flexibility of getTagKeys and getTagValues so switched the PR to addressing that.
So will move this change to a different PR.

Instead of data sources having to call templateSrv.getAdhocFilters(this.name); to get the relevant filters to apply to the queries I propose passing them via DataQueryRequest.

We would of course make templateSrv.getAdhocFilters(this.name) work for backward compatibility reasons, but going forward using filters passed via the request object is a lot more flexible and clean.

Some tricky questions:

• Should we also add it to the backend query call? so technically the filters can be applied to the query on the backend. Otherwise adhoc filters will never work for public dashboards / secure querying.

Alternative

• Add adhocFilters to DataQuery (so they are scoped to each query so you can technically issue queries in one call to DataSourceApi.query with only some of the queries having adhocFilters.

[github-actions]

⚠️   Possible breaking changes

(Open the links below in a new tab to go to the correct steps)

grafana-data has possible breaking changes (more info)

Console output
Read our guideline

[itsmylife]

LGTM with some questions

[aocenas]

Makes sense to me. Checked the Tempo service graph seems to work. Checked the other code but did not test prom or influx.