Improve TxInvalid notifications

[pgrange]

Why

There are two situations were a client could be notified of a TxInvalid:

1. when the client ask its own node to post an invalid transaction;
2. when the node receives some invalid transaction from another peer.

In the first case, the client sending an invalid transaction to its own node seems suspicious in the sense that the client has all the information it needs to build and post a valid transaction unless, of course, another transaction concurrently spent the UTxO it plans to spend. Today, we are trying to apply this transaction locally several times and we also broadcast this transaction to our peers, making them try to apply the transaction several times. This induce a performance cost and some noise in the peers network that will almost always end up with the transaction being rejected in the end. Instead, we could immediately reject the client transaction with TxInvalid and forget about it. It will be the client's responsibility to re-submit it later if, for some reason, it then becomes valid.

In the second case, we are notifying the client about an invalid transaction that this client never heard about before. We could improve developer experience by just not bothering the client with the transaction at all at that point in time, reducing noise here.

Also, with #904 and #988, we now keep the invalid transaction in allTxs in case it is, later, included in a snapshot. This makes sense to handle conflicting transactions with the arbitrage of the leader. That means that we can now send to the client an TxInvalid to the client for a transaction it never heard about before AND later include it as a valid one in a snapshot. Even worse in terms of noise.

What

• Transactions submitted by "our" clients via NewTx are validated against localUTxO

  • if invalid, a TxInvalid output is sent to our clients (only)
  • if valid, the transaction is broadcast as a ReqTx

• Transactions requested by peers via ReqTx are validated against localUTxO (as it is already the case)

  • if invalid, we drop the ReqTx, but do not send a client output
  • if valid, everything continues as before

How

1. When the hydra-node receives an invalid transaction from a peer and it's TTL expires, it does no send TxInvalid or any other notification to its client anymore (but it keeps logging as of today).
2. When the hydra-node receives an invalid transaction from its connected client, it rejects it immediately with TxInvalid and forgets about it. It does not propagate it to its peers.

Additional info

• We had some form of validation on NewTx in the past Align HeadLogic: Not validate tx on NewTx #745

  • this should not be a reason against this item
  • back then, we validated against the last confirmed UTxO
    • not sure why, but maybe because the GetUTxO returned to clients, i.e. the visible UTxO in the head, was querying the latest confirmed snapshot UTxO

• TBD: Should we change GetUTxO to return the localUTxO for a more consistent local view? Or both, the confirmed and local utxo?

[ch1bo]

We had validation in place on NewTx handling in the past, but it was tricky with not "getting heads stuck" too often IIRC.

Just noticed: in the api reference we still document it that way https://github.com/input-output-hk/hydra/blob/ea46f1a32085a04ec43f9c2ce270db23912c722d/hydra-node/json-schemas/api.yaml#L198