Adjust chain-following code to account for collateral inputs

[sevanspowell]

The purpose of this PR is to modify the the code that follows the blockchain to adjust the Wallet's UTxO when collateral inputs are lost due to a transaction that fails phase-2 script validation (Plutus scripts).

I have:

• Add valid script field to MkApiTransactionParams, ApiTransaction, TxMeta, Tx, and TransactionInfo.
• Modify state transition logic (when a Tx is applied to a UTxO) to account for collateral inputs.
• Add integration test for collateral inputs.
• Add property tests for state transition logic.
• Add is_valid_script field to API specification.

Issue Number

ADP-1036

[jonathanknowles]

@sevanspowell and I had a discussion about the representation of a transaction's script validity (currently represented by the Tx.txScriptValidity :: TxScriptValidity field).

After consideration, we both feel that it doesn't make sense to talk about the script validation status of a transaction that is still in the pending set: after all, transactions in this state have not yet been subjected to phase-2 validation, so we can't yet know what the outcome will be.

Therefore, we propose to:

• Change the type of Tx.txScriptValidity to Maybe TxScriptValidity.
  (This makes it possible to assign pending transactions with a script validity of Nothing.)
• Change the type of TxInfo.txInfoScriptValidity to Maybe TxScriptValidity.
• Change the definition of TxScriptValidity to:

  data TxScriptValidity
      = TxScriptValid
      | TxScriptInvalid

• Change the API definition of txScriptValidity to:

  x-txScriptValidity: &txScriptValidity
    type: string
    enum:
      - valid
      - invalid

The absence of a validity means that either:

• script validity is not supported for this type of transaction (for example, if the transaction was created in an era prior to Alonzo); or
• this transaction has not yet been subjected to script validation.

We both feel that this representation is still not completely satisfactory. Even under the revised representation, the Tx type still make it possible to represent a pending transaction that has a script validity, which of course doesn't make sense.

Ideally, we'd want to represent pending transactions with a type that doesn't have a script validity field, so it would not be possible to represent this invalid state.

However, the Tx type is deeply embedded in multiple places, and replacing this with a PendingTx type would likely be a lot of work, and almost certainly cause us to exceed our time budget for this task. So we propose to:

• Create an item of technical debt: represent pending transactions with a type that doesn't include script validity.

[sevanspowell]

https://input-output.atlassian.net/browse/ADP-1116

Technical debt ticket created 👍

[sevanspowell]

@sevanspowell and I had a discussion about the representation of a transaction's script validity (currently represented by the Tx.txScriptValidity :: TxScriptValidity field).

...

3997bf9

[jonathanknowles]

LGTM! 👍🏻

@sevanspowell thanks again for all your hard work on this!

[jonathanknowles]

bors r+

[iohk-bors]

Build succeeded:

• buildkite/cardano-wallet
• ci/hydra-build:required