Cardano Updates

Signed-off-by: JaeBrian <[email protected]>

Signed-off-by: Chris Gianelloni <[email protected]>

Some genesis tests still depend on 'TestBlock' specific logic.
Specifically, the `TestHash` (the `HeaderHash TestBlock` type family
instance) stores a number list representation of the path on the
`BlockTree` leading to the corresponding block (i.e. its prefix
`AnchoredFragment`); this is used to implement certain properties.

Here, such properties are refactored to parametric blocks by using direct
hash comparison (in some cases on the `BlockTree` trunk).

https://github.com/tweag/ouroboros-consensus-testing/pull/32/commits/3e838526a5a6d683bf12ac59297c824215c6ee78
holds a test showcasing a property of a previous refactor: namely that
the order of _fork numbers_ in a `TestHash` are not relevant for the
properties that depended on it. This alternative refactor (on
https://github.com/tweag/ouroboros-consensus-testing/pull/32/commits/dab534952a996f32bce1931b92698577c4115e26)
intended to preserve existing code structure, which was confusing, and
as such was changed in the end in search for clarity.

An important in-progress task is to make more test code
block-polymorphic; right now it is largely hardcoded to use test blocks
but this will not work for running conformance tests against live
implementations of the protocol.

We do not know the exact motivation behind making these tests monomorphic;
regardless it seems the only thing the tests require is the ability to
compute where a block is on the block tree.

Here we add a helper function to make generalize this by constructing a map
from each block hash in the tree to the `AnchoredFragment` from it to the
anchor. That fragment is a prefix of the trunk if and only if the block
is on the trunk.

The deforested block tree is used to check for block membership, and
to prevent its unnecessary regeneration many thousands of times per test,
it is implemented by adding a `DeforestedBlockTree` field to `BlockTree` to
cache it and a smart constructor that populates it correctly at definition time
and makes it possible to deconstruct a block tree into its trunk and branches
without giving access to the cached deforestation.

GHC's pattern match checker [assumes that any case expression involving
a pattern synonym is
incomplete](https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas);
with either `-Wincomplete-patterns` or `-Wall`, GHC will report usage of
such patterns an incomplete pattern match like this:

```
    Pattern match(es) are non-exhaustive
    In an equation for ‘mkProperty’:
        Patterns of type ‘GenesisTestFull blk’,
                         ‘StateView blk’ not matched:
            (GenesisTest _ _ _ _ (Test.Consensus.BlockTree.RawBlockTree _ _ _)
             _ _ _ _ _ _ _)
            _
```

For this reason we add a `COMPLETE` pragma to let GHC know that `BlockTree` is
in fact a complete set of patterns for deconstructing a block tree.

Here we generalize all uses of unnecessarily-specified `TestBlock`s to
instead be parametric `blk`s. For this we introduce two new type classes.

The `IssueTestBlock` class abstracts the operations needed to produce
blocks during chain generation.

The `HasPointScheduleTestParams` class abstracts the parameters needed to run
the point schedule tests. We invoke `getProtocolInfoArgs` at the beginning of
a test, and use it to construct a `ProtocolInfo`, which in turn provides both a
`TopLevelConfig` and an `ExtLedgerState`. The requirement of `IO` comes
from needing to eventually parse cardano config files.
A key point of entry for this change is found on
`PeerSimulator.Run.nodeLifecycle`, where the `ProtocolInfo` is delivered,
enabling the generalization of the simulation to arbitrary blocks.

We provide instances for `TestBlock`.

Co-authored-by: Nathan Bloomfield <[email protected]>
Co-authored-by: Xavier Góngora <[email protected]>