Add CBOR encoded Datum

[sorki]

Introduces txDatumBytes field
with CBOR serialized Datum.

[kderme]

2 notes on this:

• There will probably be many changes soon on these fields with Next hard fork support #1081
• Many of these serialisations can be avoided, since if a datum is already in db, it doesn't need to be inserted again. So we should first do a query based on the unique hash and do the serialisation only if needed. This is something we can do for many existing fields (mostly datum and scripts) and doesn't apply only to this pr.

[sorki]

There will probably be many changes soon on these fields with Next hard fork support #1081

Noticed! I think that's fine, this will be especially useful with inline datums.

Many of these serialisations can be avoided, since if a datum is already in db, it doesn't need to be inserted again. So we should first do a query based on the unique hash and do the serialisation only if needed. This is something we can do for many existing fields (mostly datum and scripts) and doesn't apply only to this pr.

I've added two commits to address this for scripts and datums.

[sorki]

Many of these serialisations can be avoided, since if a datum is already in db, it doesn't need to be inserted again. So we should first do a query based on the unique hash and do the serialisation only if needed. This is something we can do for many existing fields (mostly datum and scripts) and doesn't apply only to this pr.

Note that it isn't possible to do this in generic way since Persistent generated types have strict fields.

λ: :i Datum
type Datum :: *
data Datum
  = Datum {datumHash :: !ByteString,
           datumTxId :: <snip>
           datumValue :: !(Maybe Text),
           datumBytes :: !ByteString}

It's tempting to also rename Datum value to json so it is similar to e.g. Script or TxMetadata. Not sure if it's worth the breakage. What do you think?

[erikd]

Closed in favor of #1136 .