Tracking issue: Prometheus compatibility MVP

[flyingmutant]

Initial Prometheus compatibility support: scraping, remote write, PromQL.

• speed up ClickHouse access by using https://github.com/ClickHouse/ch-go
• check the details of how VictoriaMetrics downsampling works (do MetricsQL query results looks the same no matter the downsampling?)
• decide if we'll continue to use Prometheus PromQL implementation or migrate to MetricsQL
• remove all fancy SQL mapping features and focus on in-memory computation on raw data

Setup:

• setup StatsHouse agents on all nodes of our biggest k8s cluster
• start scraping several big k8s (or node_exporter) metrics using k8s service discovery, probably prefixing them for namespacing (is this related to Tracking issue: group budgets #110?)
• setup Prometheus/VM scraping of the same metrics
• compare standard Grafana dashboards with StatsHouse vs Prometheus/VM data source

Optimizations:

• translate regexp label selectors into SQL IN matches
• consider making all internal operations operate on int tag values, translating to strings only before returning the result

Misc. things:

• When scraping OpenMetrics, we don't have count to associate with value #133

Out of MVP scope:

• making sure PromQL is a superset of /api/query (e.g. topk semantics)
• protobuf scraping

Histograms:

• https://docs.google.com/document/d/1cLNv3aufPZb3fNfaJgdaRBZsInZKKIHo9E6HinJVbpM/edit#
• https://promcon.io/2022-munich/talks/native-histograms-in-prometheus/
• https://valyala.medium.com/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350
• https://valyala.medium.com/there-are-the-following-essential-differences-between-prometheus-histograms-and-victoriametrics-de3e7f3cf2f0

See also:

• https://uptrace.dev/get/querying-metrics.html
• https://prql-lang.org/