Explicit sanity checks for Transaction Skeletons

[carlhammann]

The problem
We sometimes accidentally generate TxSkels that are invalid for reasons like missing inputs, negative Ada amounts, etc. (At least I hope I'm not the only one prone to such mistakes.) Yesterday, I spent more than an hour debugging because of a negative Ada amount that sent the validation into a loop, somehow.

Possible solution/Question
I'd like to have a function isSane :: SanityOptions -> TxSkel -> Bool, maybe also a function sanitize :: SanityOptions -> TxSkel -> TxSkel, for some suitable type SanityOptions, that I can call on my TxSkel and figure out if and how it is broken before handing it to validation.

If something like that already exists, it's at least hidden enough that I've not yet found it.

[VictorCMiraldo]

I'm generally against adding a function sanitize because when we try to validate a transaction we will already get a number of errors indicating what's wrong with it.

I do agree that the amount of processing that happens under the hood with transaction processing is too much and can cause confusion.

[carlhammann]

I think this is not anymore relevant with the attack language as of PR #154 merged.