[Consensus] processing own block identically to other proposals [increase code consistency]

Context

At the moment, the MessageHub directly submits own proposals to the HotStuff event loop without them going through the compliance engine.

https://github.com/onflow/flow-go/blob/5dfb05ce21739c27046e14a497a61e5c99b02fb7/engine/consensus/message_hub/message_hub.go#L336-L337

One of the important tasks of the compliance engine is to persist validated blocks in the DB. In contrast, the node's own proposals are persisted during the building process.

Suggestion

I think it would help reduce complexity to treat our own blocks exactly the same as external blocks as much as we can. Thereby, we avoid extra code and special cases. In particular, I think it is totally fine for our own blocks to undergo verification. Other nodes have to do the same work before voting. I feel there is little use for the proposer to skip the verification, because the proposer is the only node that can do this, i.e. we don't speed up the consensus hot-path. I just don't think it is worth the extra complexity in the code.

Potential approaches:

1. use generics for blocks: where the block has a type-parameter for the payload. At the moment, we have different types for main and cluster consensus:

   • https://github.com/onflow/flow-go/blob/5dfb05ce21739c27046e14a497a61e5c99b02fb7/model/flow/block.go#L32-L37
   • https://github.com/onflow/flow-go/blob/5dfb05ce21739c27046e14a497a61e5c99b02fb7/model/cluster/block.go#L27-L32

   where the only difference is the payload type.

2. Alternatively, the EventHandler and all core-consensus components could work with a block represented by an interface. This would be quite similar to the existing implementation, because the consensus already defines its own abstracted block: https://github.com/onflow/flow-go/blob/5dfb05ce21739c27046e14a497a61e5c99b02fb7/consensus/hotstuff/model/block.go#L9-L18 If different blocks types could all implement the same interface

3. A third option would be to change the pipeline for block production:

   • The EventHander triggers block production asynchronously
   • SafetyRules would allow concurrent access: The Event-Hander would send block proposals to SafetyRules for. The block proposer would interact with SafetyRules to get the block signed at the end of the construction process.

Start with engine/consensus/message_hub/message_hub.go and trace how own proposals reach the HotStuff event loop versus the compliance engine. Read model/flow/block.go, model/cluster/block.go, and consensus/hotstuff/model/block.go, then compare the EventHandler and SafetyRules paths. Done means the chosen design consistently handles own and external proposals without unnecessary special cases.