[Leios prototype] Migrate EB announcement to Praos header

[bladyjoker]

Resolves input-output-hk/ouroboros-leios#837

DONE

• Move the EB announcement from the Ledger Block to the Praos Header
  • Add EbAnnouncement type that holds an EbHash and its size!
  • Remove the certifies field
• Move the LeiosState from the Ledger to the ChainDepState
  • Adds 'cummulative' EB size tracking in the state (TODO: Grafana this)
• Move the Certificate from the Ledger into Consensus
  • Ugh for now I'm keeping it in the Ledger because it's easier, albeit not ideal
• Update to Ledger with backward compatible Block codec
• Introduces ForgeBlockArgs for my own sanity
• FIX: EB only diffused if announced in forge

NOTES

• ResolveLeiosBlock machinery is a hack that works! We're blindly guessing that blk might contain something that can be resolved like a LeiosCertificate and it returns a blk that hopefully has a fully resolved blk that can be applied. Imo a morally correct approach would to have data RankingBlock blk = LedgerRb blk | CertRb LeiosCertificate which we can use to make such distinction and manage the resolution process here and elsewhere in the abstract code base where that distinction matters (like the ForgeLoop)
• applyBlock currently does resolveLeiosBlock and then tickAndReapply which is not incorrect as in the case of there being a Leios Cert, we need to base changes from the associated EB on top of the prev Ledger State (I think that means we shouldn't tick?)
  • see [Leios Prototype] Correct EB application input-output-hk/ouroboros-leios#857
• Apropos tx-centrifuge it doesn't seem like there's any way around breaking the API BlockFetch. For the current pragmatic solutions we hide the Certificate behind the blk and therefore BlockFetch will happily return you a Certificate which will break tx-centrifuge. That being said, ChainSync is also necessarily having a breaking change since we added new fields to the PraosHeader.

[ch1bo]

ldfta looks like your cat walked around on your keyboard 🐱