Clarify which phase1 validation is skipped for isValid == False transactions

[lehins]

Figure out a consistent story about Tx for phase2: what should be validated what should not.

It would be useful to create a document that outlines all parts of the transaction that are epxected to be valid when transaction itself is marked as phase2 invalid.

It is possible that we do some redundant checks that might not be necessary for such transactions.

It is important to note in such document that by default it is expected for all transactions to be phase1 valid, because normal operations of the mempool will prevent phase1 invalid transactions. However, the protocol does not prevent some custom version of the node to add phase2 invalid transactions to the chain that have some aspects of such transactions to be invalid, because those aspects do not affect the ledger state.

Therefore, this ticket could be phrased slightly differnetly:

Document exactly which parts of the transaction are validated, whenever isValid == False

[lehins]

Some notes that come to mind right now that should be captured in such documentation:

• Certificates are not being checked for phase2 invalid. Dig up some history and document why.
• UTXO[_|W|S] rules are still executed in case of phase2 validation failure. In other words all inputs are expected to be present regardless if the are spent or not. This is necessary because reference scripts could be coming from reference or regular inputs. Also we need everything for script execution, such as spending datums as hashes or inline, because scripts are executed even in case of phase2 failure.
• phase2 validation happens upon entry to mempool, but not during block minting
• phase2 validation cannot rely on accuracy of isValid flag. Point out memoization from Implement memoization interface for transaction validation #4852