consensus: remove maxTxCapacityOverride from the NodeKernel
A couple weeks ago, Edsko's insight set us on the path: the abstract Consensus
layer need not know about the limits on the size of block. That is ledger
specific; so only the atomic ledgers' (Byron, Shelley, etc -- not the
HardForkBlock) forge functions needed to query and enforce that limit.
We later realized that this same insight applies to the user-submitted
overrides of the ledger limits: the abstract Consensus layer receives a
`ProtocolInfo` structure from the downstream user. That includes `BlockForging`
structures, which include partial applications of the atomic forge functions.
When the downstream user builds the `ProtocolInfo`, they can supply the user's
overrides there, so that the abstract layer is never involved.
As a result, the `maxTxCapacityOverride` field is now vestigial.
This may seem like splitting hairs, since we _also_ provide a convenience
interface for creating `ProtocolInfo` (and hence `BlockForging`) values. But
it'll pay off to keep the separable concern separated. EG The abstract
Consensus layer interface works only at the top-level `blk` type, which meant
we would have needed a representation of overrides for `HardForkBlock`. The
`ProtocolInfo` convenience interface, however, is not abstract, and so it can
pass the right overrides to the right atomic forge functions as its building up
the inputs (eg `NP` values) for the abstract interface. So now the
`HardForkBlock` logic need not include anything at all about overrides (it
simply knows how to combine lists of `BlockForging`, which now handles
Co-authored-by: Pawel Szulc <[email protected]>