Cardano Updates

This commit uses a version of persistent that has been modified to add
proper Word64 support.

Previously when the schema used `Word64` as the column type, Persistent
would use `SqlInt64` as the SQL representation which means that `Word64`
values above `maxBound :: Int64` would be stored as negative values in
the database. That is fine for a database only accessed from Haskell but
is a pain in the neck when the database is used as an interop layer for
other languages.

This commit uses a version of persistent that has been modified to add
proper Word64 support.

Previously when the schema used `Word64` as the column type, Persistent
would use `SqlInt64` as the SQL representation which means that `Word64`
values above `maxBound :: Int64` would be stored as negative values in
the database. That is fine for a database only accessed from Haskell but
is a pain in the neck when the database is used as an interop layer for
other languages.

This commit uses a version of persistent that has been modified to add
proper Word64 support.

Previously when the schema used `Word64` as the column type, Persistent
would use `SqlInt64` as the SQL representation which means that `Word64`
values above `maxBound :: Int64` would be stored as negative values in
the database. That is fine for a database only accessed from Haskell but
is a pain in the neck when the database is used as an interop layer for
other languages.

Update dependencies.

This was particularly painful because there was a leftover reference
to the old cardano-ledger repo which was pulled in cardano-ledger-specs
some time ago.

update for latest version of cardano-client

167: Version 2.1.0 r=disassembler a=erikd



Co-authored-by: Erik de Castro Lopo <[email protected]>

Shelley: Add a deposit column to tx table

The type of this column is `Int64` allowing for positive values to
represent a deposit when a pool is registered and a negative value
to represent a refund when the pool is de-registered.

An attempt was made to add Shelley era accounting validation but that
still fails because db-sync needs more information from the ledger that
is not available on the chain.

The type of this column is `Int64` allowing for positive values to
represent a deposit when a pool is registered and a negative value
to represent a refund when the pool is de-registered.

Closes: https://github.com/input-output-hk/cardano-db-sync/issues/150

add - indexes for block(time) and tx_out(address).

These two indexes significantly improve the performance of sql queries
generated by hasura/cardano-graphql for simple graphql queries.

For examples of such graphql queries please see

https://github.com/Emurgo/yoroi-graphql-migration-backend/blob/7c29a289f28f7038ea5071046c435231a2199774/src/services/utxoForAddress.ts

164: Epoch: Fix the epoch update logic r=disassembler a=erikd



Co-authored-by: Erik de Castro Lopo <[email protected]>

This meets the requirements of:
* When syncing, the rows for old epochs are only updated once after the
  whole epoch has been retrieved.
* The point above is true even when the node is syncing (as opposed to
  following). Specifically, the TipBlock value provided by the node over
  the chain sync protocol is useless because it reports node tip, not
  network wide chain tip).
* Only updates the current epoch when we are close to the actual chain
  tip.

Closes: https://github.com/input-output-hk/cardano-db-sync/issues/111
Closes: https://github.com/input-output-hk/cardano-db-sync/issues/139