Fix forks in AuRa

[jmederosalvarado]

Summary of the changes

Most changes are refactors that I think improve the readability of the code. The main functional change is in the way we decide whether to call the validator contract finalizeChange function at the beginning of the block processing, this now no longer depends on some in-memory state being initialized having to be kept from the processing of block n to the processing of block n+1. Additionally, we are no longer using the AreFinalized field in PendingValidators, we keep it only for backward compatibility with existing databases. The code could probably be further improved to be more robust, especially when handling reorgs, however, since reorgs have not caused any issues so far, and it seems unlikely that they do so because of the way AuRa works, we can ignore this and keep the changes as simple as possible for now.

Changes:

• Makes some adjustments to ContractBasedValidator class in AuRa code to prevent forks caused by invalid blocks

Types of changes

What types of changes does your code introduce? Put an x in the boxes that apply

• [x] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation Update
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] Other (please describe):

Testing

Requires testing

• [x] Yes
• [ ] No

In case you checked yes, did you write tests??

• [ ] Yes
• [x] No

Comments about testing

We should full sync and fast sync all possible AuRa networks in addition to running this code in a gnosischain validator for some time.

[LukaszRozmej]

Successful POSDAO Test runs: https://github.com/NethermindEth/nethermind/actions/runs/3154610051 https://github.com/NethermindEth/nethermind/actions/runs/3154533644

[LukaszRozmej]

Are we progressing with this?