Cardano Updates

Update dependencies to be the same as cardano-node

This was incredibly painful due to:

* Metadata to JSON changes in the 'node' repo which both drasitcally changed
  and removed functionality that 'db-sync' was using.
* The added 'era' parameterisation in the 'ledger-specs' code for the protocol
  param data type which resulted a cascade of type errors which did not obviously
  help figuring out the solution.

Update db-sync to maintain a copy of ledger state

Ledger state is not persisted to disk. This means the db-sync process
can be killed and when restarted, restore the ledger state from disk.
However, when syncing the chain, not every ledger state is persisted
so the database may need to be rolled back to a slot number where a
ledger state esists.

While syncing the chain, only every 10000th ledger state is persisted
but when following the chain, every ledger state is saved. In either
case, only the last 8 ledger states are stored to disk. That means
that if fully synced, rollbacks of more than 8 block are no longer
possible.

Ledger state is not persisted to disk. This means the db-sync process
can be killed and when restarted, restore the ledger state from disk.
However, when syncing the chain, not every ledger state is persisted
so the database may need to be rolled back to a slot number where a
ledger state esists.

While syncing the chain, only every 10000th ledger state is persisted
but when following the chain, every ledger state is saved. In either
case, only the last 8 ledger states are stored to disk. That means
that if fully synced, rollbacks of more than 8 block are no longer
possible.

LedgerState is now available where it will be used.

Store current 'LedgerState' in a 'TMVar', thread it through to where
it is needed and update it with a bare minimum of validation
(blockPrevHash matches the hash of the most recently applied block).

In order to correctly build and maintain ledger state 'db-sync'
needs to construct a 'LedgerState' configuration. This was incredibly
difficult because the ledger state config is buried within a
'TopLevelConfig' and building that is difficult because it requires
a bunch of config parameters that 'db-sync' does not otherwise care
about.

Release 5.0.1

db-sync: Reject TxMetadata objects containing NUL characters

TxMetadata is stored as JSON and that JSON is stored in a 'jsonb' column
in PostgreSQL. However, there are limitations to that Postgres 'jsonb'
data type. Specifically, it cannot contain Uniciode NUL characters. This
temporary fix simply drops TxMetadata JSON objects that would otherwise
be rejected by Postgres. Hopefully a better solution will be will be
dreamt up and implemented later.

Temporary workaround fix for:
https://github.com/input-output-hk/cardano-db-sync/issues/297

TxMetadata is stored as JSON and that JSON is stored in a 'jsonb' column
in PostgreSQL. However, there are limitations to that Postgres 'jsonb'
data type. Specifically, it cannot contain Uniciode NUL characters. This
temporary fix simply drops TxMetadata JSON objects that would otherwise
be rejected by Postgres. Hopefully a better solution will be will be
dreamt up and implemented later.

Temporary workaround fix for:
https://github.com/input-output-hk/cardano-db-sync/issues/297