Nested content inside a block

Consider a simplified version of the hard fork combinator, defining

type HardFork a b = Either a b

Then encoding Hardfork ByronBlock ShelleyBlock is easy, in the same way that we encode any Either. The header of such a block will have type

HardFork (Header ByronBlock) (Header ShelleyBlock)

and encoding those (for example, to send them across the network) is similarly trivial. But now suppose we want to read a header from disk. We do not store headers directly, but instead store the blocks. The DB will know the offset and length (both in bytes) of the header inside the block, but how do we decode such a header? If it's a Byron block, we should use the decoder for Header ByronBlock, and similarly for Shelley, but how should we express this more generally?

Here is where HasNestedContent comes in. Continuing the example, we can unnest a Header (HardFork ByronBlock ShelleyBlock) into a pair of values, where the first value (a NestedCtxt) tells us what type of block we have, and the second value gives us the actual header. So, if the first value says "this is a Byron block", the second value is a Header ByronBlock, and vice versa. In other words, this is a dependent pair.

This then solves the serialisation problem: we expect a dependent decoder which, given a NestedCtxt identifying the block type, decodes the raw bytes from the block into the type indicated by that NestedCtxt.

TODO: We could perhaps define this independent of blocks in GenDepPair.

Context identifying what kind of block we have

In almost all places we will use NestedCtxt rather than NestedCtxt_.

Version of NestedCtxt_ with the type arguments swapped

NestedCtxt must be indexed on blk: it is the block that determines this type. However, we often want to partially apply the second argument (the functor), leaving the block type not yet defined.

Hide the second type argument of some functor

SomeSecond f a is isomorphic to Some (f a), but is more convenient in partial applications.