refactor(blooms): Delete outdated metas

[salvacorts]

What this PR does / why we need it:
In This PR we implement deletes of outdated metas and blocks. Here's how it work:

1. Builders send back created metas to the planner
2. Planner aggregates all the newly created metas for each table and tenant combination
3. Looking at the original metas and the new ones, identify outdated metas
4. Delete outdated metas along with their blocks

Special notes for your reviewer:

• I refactored the planner.loadWork into planner.loadTenantWork which now returns a map of table->tenant->[]ownsershipBounds
• Also refactored planner.RunOne to:
  1. Call planner.loadTenantWork
  2. Create and enqueue tasks for each table - tenant tuple. Computing the tasks remains the same.
  3. For each table - tenant tuple, call planner.processTenantTaskResults which will wait for all tenants to complete and handle deletion.

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]

This may spawn quite a lot of goroutines.

Idea: Could we use a single results channel? I guess then the problem would be to know when a tenantTable is done, right?

[salvacorts]

I guess then the problem would be to know when a tenantTable is done, right?

Correct.

This may spawn quite a lot of goroutines.

Indeed. On the other hand, I have this issue open for adding parallel workers to the planner. We can parallelize tenant-tables tuples across those workers and therefore limit the number of goroutines that would be spawned to wait for responses to the number of workers.

This would be similar to how the bloom-compactor currently handles parallelism:

loki/pkg/bloomcompactor/bloomcompactor.go

Line 410 in a9345d0

err := concurrency.ForEachJob(ctx, c.cfg.WorkerParallelism, c.cfg.WorkerParallelism, func(ctx context.Context, idx int) error {

So I'd address this there. I'll add a TODO.