chore(mixin): Update dashboards for bloom components

[chaudum]

What this PR does / why we need it:

• Update bloom gateway dashboard
• Replace bloom compactor with bloom build dashboard

Special notes for your reviewer:

Followed the instructions

// !--- HOW TO UPDATE THIS DASHBOARD ---!
// 1. Export the dashboard from Grafana as JSON
//    !NOTE: Make sure you collapse all rows but the (first) Overview row.
// 2. Copy the JSON into `dashboard-bloom-xxx.json`
// 3. Delete the `id` and `templating` fields from the JSON

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[rfratto]

I found a few minor issues in the dashboards but otherwise LGTM. I only left my comments on the compiled-ssd mixin, but I think what I found probably applies to all copies of them.

[rfratto]

This panel was blank for me, while "Found/Skipped/Missing series" wasn't. Bug?

[chaudum]

This seems to be a bug in Loki where we don't record series any more:

sum(rate(loki_bloom_recorder_series_total{cluster="$cluster", job="$namespace/bloom-gateway", type="filtered"}[$__rate_interval]))

Does not yield anything, where else

sum(rate(loki_bloom_recorder_chunks_total{cluster="$cluster", job="$namespace/bloom-gateway", type="filtered"}[$__rate_interval]))

does

[rfratto]

With a 12h time range, this fails with

execution: query processing would load too many samples into memory in query execution

It works with a 1h time range though. Should we change the query to load less samples?