Inline datums

[carlhammann]

This PR proposes a design for inline datums:

• On transaction outputs, you have Either Pl.DatumHash a instead of a plain a as the type of datums. The left alternative corresponds to an output with a datum hash, the right alternative to a transaction with an inline datum.
• Consequently, the type of utxosSuchThat and utxosSuchThisAndThat must change to reflect this new datum type. If we used a datum hash on a transaction output, the MockChain doesn't know the full datum, and we can therefore only return the hash.
• Also, validateTxSkel needs an extra argument to provide the corresponding data for all of these un-resolvable datum hashes: If we want to consume an UTxO that only has a datum hash, we must still be able to provide the concrete datum to run the validator (because that datum is an argument to the validator). (BTW: There's validateTxSkel', which defaults this extra argument to an empty map, and can be used whenever there are no data or only inline data. At the moment, all of the tests for the attack language use inline data, and consequently rely on this function.)

This last point is also what I do not like about this design: In order to write a transaction that consumes an UTxO with a datum hash (which I assume will still be the "normal case") you'll have to keep track of the datum on that UTxO yourself, cooked won't help you. But is it safe to assume that we knew this datum when we created the UTxO in the first place? In that case, It would be simple to change the type Either Pl.DatumHash a of transaction output datums to something like

data TxSkelOutDatum a = TxSkelOutDatum a | TxSkelOutDatumHash a

This would have the intended meaning that we always know the full datum while we create the transaction output, but sometimes we only include its hash on the transaction, but remember the complete datum in the MockChainState.

You can see the interface in action in the tests for inline datums.

[mmontin]

Here are some feedback / questions about this PR :

• The design makes a lot of sense and seems rather logical and straightforward regarding the requirements of the feature
• About validateTxSkel requiring an additional argument: I don't understand why. Don't we have access to this map within the MockChain and associated MockChainST ? Making the validation depending on an explicit map that could differ from the one in context seems odd. Most likely, there's something I miss in the challenges that you raise.

[carlhammann]

This PR has now served its purpose as a draft for inline datums. With PR #206, this feature is now implemented much more elegantly, and merged into ch/spendableout-types, which will soon be merged into ch/hedge-v2.