Tx refscript size check

[lehins]

Description

This PR does two things:

• Adds a new predicate failure for the total max size of reference scripts that can be used in any transaction
• Moves the ConwayTreasuryValueMismatch predicate check into the section that validates isValid == True transactions. There is no need to validate this value for phase2 failed transactions.

Checklist

• [x] Commit sequence broadly makes sense and commits have useful messages
• [x] New tests are added if needed and existing tests are updated
• [x] When applicable, versions are updated in .cabal and CHANGELOG.md files according to the versioning process.
• [x] The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• [x] All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
• [x] Code is formatted with fourmolu (use scripts/fourmolize.sh)
• [x] Cabal files are formatted (use scripts/cabal-format.sh)
• [x] hie.yaml has been updated (use scripts/gen-hie.sh)
• [x] Self-reviewed the diff

[lehins]

The only thing that I wonder about this is is: how come this check is in Ledger

I didn't really think too much which rule this check should go into, but since you bring it up, I believe LEDGER is a good home for it, because it doesn't check any individual reference script, but rather their total size. In other words MalformedReferenceScripts or OutputTooBigUTxO check validity of individual components of a transaction, while ConwayTxRefScritpsSizeTooBig is a check on a transaction level.

In general location of this type of checks is very subjective. I am not sure why, for example ConwayWdrlNotDelegatedToDRep and ConwayTreasuryValueMismatch are defined in LEDGER either :shrug: Probably has to do with parts of the state they need to access, rather than with anything else.