slot-based-collator: Allow multiple blocks per slot

[skunert]

Summary: This PR enables authoring of multiple blocks in one AURA slot in the slot-based collator and stabilizes the slot-based collator.

CLI Changes

The flag --experimental-use-slot-based is now marked as deprecated. I opted to introduce --authoring slot-based instead of just removing the experimental prefix. By introducing the authoring variant, we get some future-proofing in case we want to introduce further options.

Change Description

With elastic-scaling, we are able to author multiple blocks with a single relay-chain parent. In the initial iteration, the interval between two blocks was determined by the slot_duration of the parachain. This PR introduces a more flexible model, where we try to author multiple blocks in a single slot if the runtime allows it.

The block authoring loop is largely the same. The SlotTimer now lives in a separate module and is updated with the last seen core count. It will then trigger rounds in the block-building loop based on the core count.

This allows some flexibility where elastic-scaling chains can run on a single core in quiet times. Previously, running on 1 core with a 3-core elastic-scaling chain would result in authors getting skipped because the slot_duration was too low.

Parameter Considerations

The core logic does not change, so there are a few things to consider:

• The ConsensusHook implementation still determines how many blocks are allowed per relay-chain block. So if you add arbitrary cores to an async-backing, 6-second parachain, can_build_upon in the runtime will deny block-building of additional blocks.
• The MINIMUM_PERIOD in the runtime needs to be configured to allow enough blocks in the slot. A "classic" configuration of SLOT_DURATION/2 will lead to slot mismatches when running with 3 cores.
• We fetch available cores at least once every relay chain block. So if a parachain runs with a 12-second slot duration and 1 fixed core, we would still author 2 blocks if the parachain runtime allows it.

[skunert]

/cmd prdoc --audience node_operator --bump major

[michalkucharczyk]

1st round, will get back to it.

[skunert]

/cmd fmt

[michalkucharczyk]

nit: maybe mentioning some recommended values in PR description for the following items would make it easier to integrate?

The ConsensusHook implementation still determines how many blocks are allowed per relay-chain block. So if you add arbitrary cores to an async-backing, 6-second parachain, can_build_upon in the runtime will deny block-building of additional blocks.
The MINIMUM_PERIOD in the runtime needs to be configured to allow enough blocks in the slot. A "classic" configuration of SLOT_DURATION/2 will lead to slot mismatches when running with 3 cores.