Cardano Updates

Previously, the initial "faked" genesis block was assumed to have
an `id` of `1`. This is not always the case so the query has been
changed so that we use the block where `epoch_no` is `NULL`.

Need to bump `cardano-api` to get new API functionality needed for
Allegra support.

Also needed to adapt to ProtocolCardano changes in consensus.

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

This was the quickest possible thing that would be likely to support
Allegra. This was achieved by copying the Shelley support to Allegra,
renaming functions as types as needed and then fixing the stuff that
was broken.

The optimal solution is to have one file that supports the Shelley,
Allegra and Mary eras.

This was the quickest possible thing that would be likely to support
Allegra. This was achieved by copying the Shelley support to Allegra,
renaming functions as types as needed and then fixing the stuff that
was broken.

The optimal solution is to have one file that supports the Shelley,
Allegra and Mary eras.

Thanks to Moritz who did all the hard work to make the Nix stuff
work.

Co-authored-by: Moritz Angermann <[email protected]>

* Types now support Allegra/Mary, but the code will panic if any real
  Allegra/Mary code is triggered.
* Also buildable with ghc 8.10.

Thanks to Moritz who did all the hard work to make the Nix stuff
work.

Co-authored-by: Moritz Angermann <[email protected]>

* Types now support Allegra/Mary, but the code will panic if any real
  Allegra/Mary code is triggered.
* Also buildable with ghc 8.10.

When blocks and rollback notifications arrive via the chainsync protocol,
they are put in a queue and then a separate thread reads from the queue and
operates on the DB. When ledger-state management was added, code to apply a
block to a ledger state was added at the read end of the queue, but the
rollback handling was incorrectly added at the write end of the queue.

The solution to the problem is trivial, move the ledger state rollback
handling from the write end of the queue to the read end.

Closes: https://github.com/input-output-hk/cardano-db-sync/issue/398

Maintenance of ledger state uses code in the consensus packages as a library.

* There are two versions of a function to apply a block to a ledger state; a
  slow one that does full checking and fast one that does fewer checks.
* Since db-sync is getting blocks that have already been validated by the node,
  it seemed sensible to use the fast version.
* I had been told that the checks in the fast version included checking that the
  block's previous hash matches the value of the head hash in the ledger state,
  but this hash check was not being done.

The previous lack of hash checking means the problem was not detected until the
start of the next epoch.

When blocks and rollback notifications arrive via the chainsync protocol,
they are put in a queue and then a separate thread reads from the queue and
operates on the DB. When ledger-state management was added, code to apply a
block to a ledger state was added at the read end of the queue, but the
rollback handling was incorrectly added at the write end of the queue.

The solution to the problem is trivial, move the ledger state rollback
handling from the write end of the queue to the read end.

Closes: https://github.com/input-output-hk/cardano-db-sync/issue/398

Maintenance of ledger state uses code in the consensus packages as a library.

* There are two versions of a function to apply a block to a ledger state; a
  slow one that does full checking and fast one that does fewer checks.
* Since db-sync is getting blocks that have already been validated by the node,
  it seemed sensible to use the fast version.
* I had been told that the checks in the fast version included checking that the
  block's previous hash matches the value of the head hash in the ledger state,
  but this hash check was not being done.

The previous lack of hash checking means the problem was not detected until the
start of the next epoch.

Mainly for debugging. When this aborts the program, it can leave the
database in a werid state.

Fix maintenance of ledger state

When blocks and rollback notifications arrive via the chainsync protocol,
they are put in a queue and then a separate thread reads from the queue and
operates on the DB. When ledger-state management was added, code to apply a
block to a ledger state was added at the read end of the queue, but the
rollback handling was incorrectly added at the write end of the queue.

The solution to the problem is trivial, move the ledger state rollback
handling from the write end of the queue to the read end.

Closes: https://github.com/input-output-hk/cardano-db-sync/issue/398