feat: update blockbuilder to use scheduler for fetching jobs

[ashwanthgoli]

What this PR does / why we need it:

• Updates block builder to use scheduler APIs for getting jobs and updating their status
• Adds a sync loop to periodically call syncJob to update the status of inflight jobs
• Tries to rename all instances of slimgester to blockbuilder
• Moves chunk appender code to a separate file appender.go
• Removes controller as it is no longer required

Special notes for your reviewer:
I renamed slimgester.go to blockbuilder.go in the last commit, so github does not show the diff anymore and treats it as a new file. Please check the first two commits to view the new changes made in builder.go

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

[owen-d]

Left a few things to fix, but giving approval to unblock you.

[owen-d]

Why do we need this? Jobs are completed all-or-nothing because tsdbs are built at the end. The job itself contains the offset range

[owen-d]

I think it's much simpler if the jobs are predetermined at the scheduler. This was the initial design and although it does introduce a bit of lag (we only process offsets known at the time of job creation), I think the simplicity & separation of concerns are more beneficial (at least for now).

[owen-d]

I suspect we'll need to retry when there are no jobs here, but as you said it's also possible the transport handles this

[owen-d]

This will panic b/c it's creating new clients each time, each which use the same metrics namespacing internally. Instead, we could create a single client which creates cheap copies via a WithPartition(x) -> Self or similar.

[ashwanthgoli]

not sure if it is safe to make copies of kgo.Client. we'd need separate instances of it as we mutate it while setting offset for consumption.

working around this by registering metrics only once 786186a.