aura-ext: limit the number of authored blocks per slot

[slumber]

Resolves #2544

[rphmeier]

I don't understand why this exposes a new trait ConsensusHook.

Instead, we should be exporting one or more structs from this pallet that can be plugged in as pallet_parachain_system::ConsensusHooks.

The only thing people can reasonably do right now is have a constant velocity which we clamp to '1', although in the future we will want to do stuff like read out the state of blockspace regions, claims queue, etc.

[rphmeier]

I think we had a bit of an architectural mental model mismatch.

I do see where you're coming from, with introducing a separate ConsensusHook type for Aura that determines the velocity. That could be combined with a pallet_parachain_system::FixedCapacityConsensusHook to get effectively the same behavior. At the moment, the determination of velocity and capacity are not very tightly linked.

But looking forward, both velocity and capacity will both need to be determined dynamically, e.g. by reading relay-parent state and seeing how many cores a parachain is allocated onto or similar things. That's why I chose the architecture I did: consensus engines should have one piece of code for determining capacity and velocity. parachain-system only needs to care about Capacity, not velocity. The consensus hook itself is responsible for defining velocity rules.

So what I would like to see for users is actually something like this:

impl pallet_parachain_system::Config for Runtime {
  // ... snip

  // Assume we are a parachain with one core, and allow only up to 4 unincluded blocks.
  type ConsensusHook = pallet_aura_ext::FixedVelocityConsensusHook<Runtime, 1, 4>;
}

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/2817212

[rphmeier]

Looks good modulo nit