[Consensus] State Sync - Request, download and apply blocks

[Olshansk]

Objective

Implement the interface that exposes the maximum & minimum blocks a node can expose and share

Origin Document

State sync block by block design: #125

Goals

• A foundation for advertising/exposing data a single node has to offer to others during state sync
• Allow another node to request, download and apply a block from the advertising node

Deliverables

• Implementation of the interface (fully integrated) that exposes the data a node has available
• Tooling and/or tests that call these endpoints to retrieve the advertised information

Non-goals

• Actual implementation of state sync

General issue checklist

• Update the appropriate CHANGELOG
• Update the README
• If applicable, update the source code tree explanation
• If applicable, add or update a state, sequence or flowchart diagram using mermaid
• Update any relevant global documentation & references
• Document small issues / TODOs along the way

---

Creators: @jessicadaugherty @Olshansk

[Olshansk]

After a first attempt at #594, we've got some new learnings and are going to start from scratch, splitting the work into smaller PRs

Notes:

• Try to avoid maintaining state in the consensus module as much as possible
• Try to avoid small boolean vars (e.g. IsSynching, etc...) in the consensus module
• Utilize persistence for the state of the node
• Use the FSM and main event bus for event handling
• Create channels to accept state sync metadata responses and block responses
• Create very small PRs, one by one

As a starting point, we will create the following micro PRs:

PR1: [Testing] Channel for FSM events

Don't mock FSM in testing. Use the existing testing infrastructure and pipe the events into the shared channel. This enables waiting & controlling the clock.

PR2: [Testing] Helpers

Avoid boiler plate code needed in hotstuff within state sync E.g. Create WaitForBlock, WaitForTransaction, etc, type helpers.

PR3: [Consensus] Adding transactions via transaction indexer

• Use the txIndexer to populate the transactions in the blocks

PR4: [Consensus] Create Block and Metadata Response Channels

• One channel to accept new metadata responses.
• One channel to accept new block responses.
• FSM events will trigger operations for the channels (e.g. aggregating the metadata responses, processing received blocks, etc...)
• Asynchronously, goroutines will be handling, processing of these channels; leave a placeholder for this in PR3.
  • One goroutine will be processing the metadata response channel.
  • Another goroutine will be processing received blocks, committing.

PR5: [Consensus] Investigate locks

• Implement the placeholders from PR4 to actually apply the block
• This will require some work / trickery related to locks

---

This is a starting point and further PRs will be needed.