Ability to run analyzers in parallel

[mitjat]

Resolves https://app.clickup.com/t/8669qdzbh

This PR

• adds a fast_sync key to each block analyzer's config, wherein the block range and parallelism can be specified
• runs those fast-sync analyzers first
• (TODO) changes "slow-sync" consensus analyzer (now at most one) so it first processes the genesis right before the first block it will analyze. If that happens to be the chain genesis document, it grabs that; otherwise, it uses StateToGenesis at an appropriate height. If it notices that at least one block after the beginning of the configured "slow" range has already been processed, it assumes genesis was already processed also, and skips genesis processing. This is different from how we've been processing genesis so far (analyze the newest chain's genesis document at most once, regardless of the configured range), but I think the new way makes more sense. It also allows the slow analyzer to do the right thing wrt genesis in any of the three scenarios:
  • it runs after fast-sync analyzers that have processed some range of blocks
  • it runs after a slow-sync analyzer (after k8s redeployment)
  • it is starting from scratch

This PR does NOT implement fast-sync behavior (= disabling dead reckoning) or parallelism tolerance inside the analyzers themselves; that happens in other PRs. So the only way to test this config in the very short term is to run "fast-sync" analyzers (that are no different from slow ones) with a parallelism level of 1.

[ptrus]

Is there any reason for this struct to be exported?

I think it makes more sense for NewConsensusAnalyzer to return value of type analyzer.Analyzer and then this struct can be made unexported.

I guess this will be updated in #389 anyway.

[mitjat]

Urgh that's something that's been inconsistent across analyzers for a while, and I never cared enough to unify it. Fixed now; all analyzers now return the type-erased analyzer.Analyzer.

A reason (beyond not caring enough) I didn't want to touch this bit of code is that the naming was split between two conventions: Calling every analyzer Main, or calling every analyzer in module mymodule MyModuleAnalyzer. I went with the latter now; I expect opinions/preferences will differ. I don't care which one we use (beyond thinking that Main should be renamed to Analyzer or MainAnalyzer if we go there), but I don't really want to deal with bikeshedding and editing. If anybody wants to rename further, I welcome PRs (or commits to this PR).

[mitjat]

This was closed automatically when I accidentally deleted the remote (= github) branch.
Will reopen a new PR.