Ledger state validation (MS5.5)

[buddhisthead]

Description

"Expose any errors detected by ledger state modules as validation errors"

Intersect Milestone

MS5.5

Acceptance Criteria

• "Verify no ledger errors in existing mainnet blocks"

This is an extension of #376 really, since correct derivation of the SPDD requires that we understand everything we are given.

• "Verify signalled failures in constructed bad Tx"

We need a mechanism to construct and inject bad Tx (see also other test requirements) - to do this for every possible error will be hard; hopefully a sample to show the mechanism will be acceptable initially.

Expected Deliverables

• "Upgrades to ledger state derivation modules (see MS1) to report errors"

Essentially every error!() in the ledger state modules needs to be converted into a ValidationStatus in a BlockValidation message and published on a cardano.validation.xxx topic, where xxx is the module.

• "Test reports"

Report showing that mainnet runs without any errors and a sample of bad transactions generate the correct validation failure (Consensus will report it)

[buddhisthead]

@shd Please assign to someone as you desire.

[shd]

This ticket has many sub-tickets, and all of them have typical info, so it's better provide one description here:

1. Collect all validation errors into ValidationError struct values, and have a list of them at the end of each message processing.

2. Check Intention enum in BlockInfo:
   a) If it is 'Apply', then work as usual, and errors are to be printed.

   b) If it is 'Verify', then no internal structures are to be updated, and the errors are to be sent to validation channel ('cardano.validation.account'), using ValidationStatus enum. For simplicity, only the first error is to be passed through the channel, although the implementation should collect all known errors, and have them in vector at the send moment.

   If no errors found, ValidationStatus::Go message is mandatory, so module must send always exactly one ValidationStatus message in 'Verify' mode.

   c) if both flags are set, then 'Apply' should take place if 'Verify' was successful (no errors) -- this may be implemented at later stage, if it is a complicated change; then a new ticket should be created, and info about that should be mentioned in the PR/this ticket.

All other functionality (like passing messages further) should work as usual.