[Persistence][Utility] Separate all CreateAndApply functions into more functional components

[jessicadaugherty]

Objective

Improve the interface exposed by UtilityContext, so it is more functional and has fewer side effects. This will make it clearer how to use it in the context of block preparation, validation and application.

Origin Document

The UtilityContext in shared/modules/utility_module.go partially exposes the following interface:

type UtilityContext interface {
	// ...
	SetProposalBlock(blockHash string, proposerAddr []byte, txs [][]byte) error
	// ...
	CreateAndApplyProposalBlock(proposer []byte, maxTxBytes int) (stateHash string, txs [][]byte, err error)
	// ...
	ApplyBlock() (stateHash string, err error)
	// ...	
}

There are various side effects, as well as implicit behaviour and expectations. For example:

• SetProposalBlock must be called before ApplyBlock
• Only the leader should call CreateAndApplyProposalBlock
• CreateAndApplyProposalBlock modifies the state (not reversible) of the chain even before other validators sign it off

Goals

• Decouple the business logic of block creation and application
• Understand the flow of block preparation, validation and application (for the assignee)
• Make the interface clearer (by improving the interface & documentation) for others to use (e.g. consensus module) and reduce side effects
• Think through ways of rolling back the changes CreateAndApplyProposalBlock because it does not imply that 2/3 of signatures were received

Deliverable

• Split CreateAndApplyBlock into CreateBlock and ApplyBlock
• Reduce the code duplication in block.go between the functions CreateAndApplyProposalBlock and ApplyBlock
• Add logs to understand to track the process of block creation and application
• Increase (a bit) test coverage for this functionality
• Search for all CreateAndApplyProposalBlock or prepareAndApplyBlock instances in the codebase and refactor those parts of the code
  • Update consensus module code
  • Update utility module code
  • Update documentation and end-to-end flows

Non-goals / Non-deliverables

• Implementing rollbacks

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

• New tests related to block creation & validation
• All tests: make test_all
• LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md

---

Creator: @jessicadaugherty
Co-owner: @Olshansk

[jessicadaugherty]

@deblasis please review and place in the correct iteration (current or next) when you have a chance. Thank you!

[deblasis]

@jessicadaugherty I think this will be handled in the current iteration.