chore(sequencer): avoid hashing proposal data in execution state

[Fraser999]

Summary

This changes the new ExecutionState in sequencer to not use hashed info, but rather keep the same information in an unhashed form.

Background

ExecutionState was recently introduced under time pressure to fix an issue. This PR fixes a few nitpicks in that code, as well as changing the approach to not use a fingerprint.

Encoding and hashing the data does not seem necessary since the sequencer only handles a single ExecutionState at any given time. The maximum size of the unhashed data will be roughly the same size as a block, and so there is no concern that this will cause resource issues.

Using unhashed data is significantly more performant. The results of quick benchmarking show that by avoiding encoding then hashing the data, performance for checking the execution state (calling check_if_prepared_proposal) improves by ~10x for empty blocks (no txs), ~50x for full blocks (1MB of txs) and ~10,000x for full blocks where the proposal data doesn't match the cached data.

The changes in this PR do not change the high-level logic around handling block execution - the state machine's states retain the same meaning and transition in the same way as before. This is only changing internal implementation details of the state machine.

Changes

• replaced the fingerprint hash with CachedProposal
• changed comments to doc comments where appropriate
• reduced visibility of execution state types to pub(super)

Testing

Existing tests updated. No further tests required.

Changelogs

No updates required - this is essentially invisible to consumers.

[joroshiba]

LGTM