chore: Split indexing into distinct steps

[benclive]

What this PR does / why we need it:
Refactor index calculation code to split the actual work into separate steps.

It works like this:

1. Each "processLogsSection" call will get a new instance of step objects. They don't hold much state so this should be fine.
2. Before reading any logs from the section, Prepare is called for each step with the stats/metadata.
3. The main calculation code handles reading the logs from the object and calls ProcessBatch for each step.
4. Finally, Flush is called on all the steps so they can write their results to the builder or do any final calculations.

A calculation context is passed to each step so they can extract the tenant ID or any other information they need.

I'm hoping this will keep things relatively tidy as more indexing stategies are introduced over time. As a plus, it also simplifies error handling around the mutex. There is no change to functionality: it is a pure refactor.

[rfratto]

nit: sharing mutex pointers can be a source of bugs because the spread of where logic is defined gets wider and it can be harder to keep track of making sure the mutex is being used properly in all places.

I'd recommend considering changing the semantics such that:

• The mutex is locked whenever we pass the logsCalculationContext to ProcessBatch/Flush
• We clarify in the interface API that implementations must not retain the builder after the call returns

[benclive]

Good idea, I've made the changes you suggested and locked the mutex before calling the step implementations.