Cardano Updates

2696: Handle exiting threads in diffusion layer r=karknu a=karknu

If a thread spawned by diffusion exits for any reason we kill
all other threads and return. This is done to ensure that the node isn't
left running in a semi-functional state, for example with the client
side working but the server has exited due to a configuration error.

Example output:
`cardano-node: Network.Socket.bind: unsupported operation (Can't assign requested address)⏎`

Co-authored-by: Karl Knutsson <[email protected]>

Some fields in the Shelley genesis config are only needed at start-up. There's
no point in keeping them in memory during the rest of the execution. In some
testing setups, e.g., for transaction benchmarking, the genesis config can be
quite large.

This also means that the `GetGetGenesisConfig` query (#2694) would only return
the compact genesis config, not the original full one.

The `ExtLedgerState` contains the `HeaderState`, which contains the
`ChainDepState`, in addition to the `LedgerState`.

This makes it possible to add the new `DebugChainDepState` query for Shelley.

The query abstraction was moved to `Ouroboros.Consensus.Ledger.Query`, as it now
depends on `Ouroboros.Consensus.Ledger.Extended`.

Some shuffling and extra utilities were required for the HFC.

Instead of:
```
import Ouroboros.Network.Util.ShowProxy
```
Do:
```
import Ouroboros.Consensus.Util (ShowProxy)
```
This reduces the number of times consensus needs to import something from
network. This will make #2614 easier.

The name was misleading: the existential type parameter was not the block, but
always sometimes else.

Introduce `ShelleyNodeToClientVersion2`, which is a requirement for the new
`GetGenesisConfig` and `GetCurrentShelleyState` queries. Submitting these
queries while using `ShelleyNodeToClientVersion1` will result in an exception
thrown by the client-side encoders, which is better than a decode failure on the
server-side (invisible to the client). The better solution would be to negotiate
a version that is high enough to allow for these queries, but we need support
from the network layer for that.

Use `CardanoNodeToClientVersion3` to enable `ShelleyNodeToClientVersion2` within
`CardanoBlock`. The Allegra and Mary eras will both use
`ShelleyNodeToClientVersion2` from the start, there's no point in supporting the
old version (too). This means we need `NodeToClientV_4` for this.

Note that the pure-Shelley versioning can do its own thing w.r.t.
`NodeToClientV_X`, it is unrelated to the numbers used for `Cardano`. So it can
simply pick the next number available, which is `NodeToClientV_3`.

Also version the `QueryHardFork`: `GetCurrentEra` requires
`HardForkSpecificNodeToClientVersion2`, which is part of a new type to version
the bits specific to the HFC itself.

Use the `Debug-` prefix instead of `Get-` to emphasise that this is only for
debugging. Do the same for the existing `GetCurrentEpochState` query.

Also drop `Current` from the name.

Fixes #2690.

This fixes the following issue:

    Query_GetGenesisConfig:             FAIL
      Exception thrown by encoder doesn't match the golden CBOR output
      Exception:
      ShelleyEncoderUnsupportedQuery (SomeBlock GetGenesisConfig) ShelleyNodeToClientVersion2 ShelleyNodeToClientVersion1
      Golden term:
      [TkBytes "helleyEncoderUnsupp",TkString "rtedQuery (Some",TkBytes "lo",TkString "k G",TkString "tGene",TkString "isConfig) ShelleyNo",TkString "eToC",TkString "ientVersion2",TkInt (-1),TkBytes "helleyNodeToClientV",TkString "rsion",TkInt (-18)]

2701: cardano-ping as a demo r=karknu a=karknu

A mux demo that uses ouroboros-network's keepalive protocol
to mimic the ping command.

Co-authored-by: Karl Knutsson <[email protected]>

A mux demo that uses ouroboros-network's keepalive protocol
to mimic the ping command.

2702: Update dependencies r=mrBliss a=mrBliss

Highlights:

* https://github.com/input-output-hk/cardano-ledger-specs/pull/1915
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1922
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1902
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1923
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1927
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1929

Co-authored-by: Thomas Winant <[email protected]>

The Cardano ThreadNet tests were failing with:

      Exception:
        out of bounds : -5999999999995992
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:77:15 in shelley-spec-ledger-0.1.0.0-IHgVjHhhJ1jYZdRhYRAbW:Shelley.Spec.Ledger.Coin

The ledger never permitted negative `Coin`s, but in the last update it has
started checking this when serialising a `Coin`.

We end up with a negative `Coin` because the value of `maxLovelaceSupply` we use
for the Shelley era is `initialLovelacePerCoreNode (= 1000) * #coreNodes`.
However, the Byron ledger state starts out with an initial balance of
6000000000000000, which subtracted from `maxLovelaceSupply`, results in a
negative `Coin`.

Fix this by using an appropriate value for `maxLovelaceSupply` in the Cardano
ThreadNet tests.

Highlights:

* https://github.com/input-output-hk/cardano-ledger-specs/pull/1915
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1922
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1902
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1923
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1927
* https://github.com/input-output-hk/cardano-ledger-specs/pull/1929

A mux demo that uses ouroboros-network's keepalive protocol
to mimic the ping command.