[Peras 27] Split degenerate BlockSupportsPeras instance

[agustinmista]

This PR has the main goal of removing the existing degenerate forall blk. BlockSupportsPeras blk instance and replace it with separate, independent ones for the several block types in the codebase that need it.

To aid with this process, we have made a couple of preliminary changes:

• Moving base Peras types into a separate O.C.Peras.Types module to keep O.C.Block.SupportsPeras as focused on the blk-dependent API as possible.
• Consolidating all the HasPeras(Vote|Cert)X classes into two, IsPerasVote and IsPerasCert, grouping all the necessary non-crypto-related projections needed to operate on Peras votes and certificates.
• Removing the PerasCfg blk associated type, in favor of keeping things simple and using the monomorphic PerasParams for now. These will likely need a major overhaul in the future when on-chain governance of these parameters becomes necessary.
• Introducing dedicated modules for MockPeras(Vote|Cert)s, containing the non-crypto mocked Peras votes and certificates that were previously hardcoded everywhere. These will still be used for certain (mostly test) block types.
• Provide an "empty" default BlockSupportsPeras instance defined in terms of Void, so Peras votes, certs, and errors are uninstantiable and can be discharged via absurd.

With this in place, the remaining changes mostly encompass the plumbing needed after removing the existing BlockSupportsPeras instance and replacing it with dedicated ones. Concretely:

• ByronBlock uses the "emtpy" instance
• ShelleyBlock proto era uses a mocked instance (to be replaced with a concrete one using real type for era ~ Dijkstra and empty ones for every other era. (@tbagrel1 is working on this on a separate PR)
• HardForkBlock xs uses a mocked instance, but will be replaced with a compositional one defined around the two previous ones (also WIP)

On the testing side:

• BlockA and BlockB both use the "empty" instance
• DualByronBlock uses the "empty" instance
• O.C.Mock.Ledger.Block.SimpleBlock c ext uses the "empty" instance
• O.C.Storage.TestBlock.TestBlock uses a mocked instance (now with a properly instantiated getPerasCertInBlock)
• Test.Util.TestBlock.TestBlockWith ptype uses a mocked instance (without any support for certificates in blocks, as it's not needed for any of the existing tests)

Finally, some general notes (notice that some of these are already covered by new issues linked in the comments below):

• There is a substantial number of instances involving type families that had to be derived using standalone deriving statements now to keep GHC happy.
• BlockSupportsPeras is still missing a forgePerasVote method. This will become evident soon when trying to write a blk-generic voting thread (BlockSupportsPeras currently misses a forgeVote method tweag/cardano-peras#248)
• Some of the new BlockSupportsPeras instances are defined via orphans in dedicated modules. This is because:
  • SerialiseNodeToNodeConstraints blk now requires SerialiseNodeToNode (PerasVote blk) and SerialiseNodeToNode (PerasCert blk) which are only in scope after PerasVote blk and PerasCert blk are established when defining BlockSupportsPeras blk
  • Some SerialiseNodeToNodeConstraints instances are already defined as orphans in their own dedicated modules, forcing us to create a new module or to define BlockSupportsPeras blk in the same one as SerialiseNodeToNodeConstraints blk (confusing!). We might be able to rearrange constraints to avoid this, but that would probably mean adding SerialiseNodeToNode (Peras(Vote|Cert) blk) as superclasses to a type-class higher-up in the chain.
  • We favored tight constraints over "umbrella" ones as much as possible to avoid having to implement unnecessary/unrelated interfaces for test blocks as much as possible.
• Mocked votes and certs are trivially validatable without errors (technically, with uninstantiable errors if being pedantic). For this to work, MockPerasVote carries its own stake. Please note this is not the case for real votes, as their stake is retrieved from the stake distribution after validation.
• Some Peras... types will become redundant and get removed in a later PR when we start integrating components.

[tbagrel1]

This was a long review ahah

General comments (when I didn't find an appropriate location to pin them):

• We still have PerasVoterId clashing with SeatIndex. Same with Point blk and PerasBoostedBlock

• ShelleyBlock and HFC block are using Mock Vote/Cert despite real vote and certs being available (Peras.{Vote,Cert}.V1)

• It also could be worth generating a list of modified files with a mention for each saying if we just updated imports/replaced constraints StandardHash -> BlockSupportsPeras, or if we did something meaninful in them. It could be useful for future reviewers

[tbagrel1]

I suggested we could move the vote-related and cert-related constraints to the IsPerasVote and IsPerasCert classes. If there is a reason why this isn't desirable, we should probably document it :)

[agustinmista]

Ok, I took another stab at this, and I think I have a decent argument to avoid doing this for now:

• Contrary to what I expected, we end up needing more constraints than before. E.g. StandardHash blk becomes necessary on every call site of a vote/cert projection, regardless of whether we need to Show, Eq, etc. a vote/cert's Point blk.

• We additionally need the same constraints for PerasError blk, but we don't have a dedicated class to add these as superclasses to, creating an inconsistency.

[tbagrel1]

Mention #wontfix-for-testnet in the PR description

[agustinmista]

#needs-a-todo(blk-dependent Peras params)

[tbagrel1]

See tweag/cardano-peras#119

[tbagrel1]

Mention #wontfix-for-testnet

[tbagrel1]

See tweag/cardano-peras#246

[tbagrel1]

Again, we need to replace this with concrete Peras.Vote.V1 for >= Djisktra eras, or at least add a TODO that says we need to do it :)

[agustinmista]

I added a TODO, also:

#needs-a-todo(use real Peras types for Shelley and HFC)

[tbagrel1]

So far I updated the bullet list in tweag/cardano-peras#73
I'll let @qnikst decide if we should create subtask with their dedicated issue

[qnikst]

@tbagrel1 item is ok for now, this way we will not lose it. We can spli to a dedicated issue in case if it can be done in later milestone or by another person.

[tbagrel1]

Looks good to me!