refactor(blooms): Add metrics for per-tenant tasks progress to planner

[salvacorts]

What this PR does / why we need it:
This PR adds two new metrics to track the build process of each tenant.

Special notes for your reviewer:

• We already expose a per-tnenat metric for the queue size:
  

  loki/pkg/queue/metrics.go

  Lines 16 to 21 in 5b8d0e6

  	queueLength: promauto.With(registerer).NewGaugeVec(prometheus.GaugeOpts{
  	Namespace: metricsNamespace,
  	Subsystem: subsystem,
  	Name: "queue_length",
  	Help: "Number of queries in the queue.",
  	}, []string{"user"}),

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
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• 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

[chaudum]

nit: I would rather run the ticker in a new goroutine

[salvacorts]

Thank you! Done

[chaudum]

nit: should we remove the metric with the tenant label completely, instead of just resetting it to 0?

[chaudum]

Also, we could then use a Counter

[salvacorts]

should we remove the metric with the tenant label completely, instead of just resetting it to 0?

AFAICT a metric cannot be explicitly removed. Can it?

we could then use a Counter

That was my first idea but a counter would make it a bit difficult to see for a given iteration, how many "new" tasks would be created. It would require using increase but setting the interval is difficult. Instead, by using a gauge, you can see the current set of tasks.

Also note that the gauge doesn't change often, but only when the build is planned.