[Persistence] TxIndexer to StateHash Bridge

[Olshansk]

Objective

The objective of this issue is to "bridge" the work being done in #302 (tx indexer integration) and #285 (first state hash implementation.

Origin Document

The interface and diagrams for the state hash computation were being done in #252 while the first implementation began in #285. However, since both of these are dependent on the integration of the tx indexer in #302, some conflicting design decisions arose.

The goal of this ticket is to unblock #302, while also capturing the results of an offline discussion that led to a decision where the "ephemeral block state" should be wholly managed by the persistence context, being a single, "roll-backable" point of reference.

Goals

• Remove ephemeral block-related state from the consensus module & utility module, and only maintain it in the persistence module
• Simply outward-facing module interfaces to only rely on primitive types
• Enable committing of a block to persistence by simply calling Commit(quorumCert); see [Core] StateHash Interfaces & Diagrams #252 for more details

After #302, #285 and this ticket is done, we should have a design that more closely resembles the following

• P2P - Wakes up consensus module (pipe for consensus module)
• Consensus - State Machine Orchestration
• Utility module - State Machine
• Postgres Context - Maintains state

Deliverable

A PR that achieves the goals and includes, but not limited to, the following changes:

• Remove lastAppHash from the consensusModule struct state & access it from the persistence layer (added n the past)
• Remove validatorMap from the consensusModule struct state & access it from the persistence layer (added n the past)
• Remove TxResult from the utility module interface (added in [TxIndexer] Integration of transaction indexer (issue-#168) #302)
• Encapsulate TxIndexer logic only inside the persistence context

Non-goals / Non-deliverables

• Implementation of the state commitment (i.e. state hash)

General issue deliverables

• Update the appropriate CHANGELOG
• Update any relevant READMEs (local and/or global)
• Update any relevant global documentation & references
• If applicable, update the source code tree explanation
• If applicable, add or update a state, sequence or flowchart diagram using mermaid

Testing Methodology

• Add new unit tests if applicable
• All tests: make develop_test
• LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

---

Creator: @Olshansk
Co-Owners: @andrewnguyen22