consensus: Reuse validated block

[fed-franz]

Summary

After introducing #1177, it might make sense to allow a block that reached a Validation Quorum to be reused if the Ratification phase fails to reach a quorum.
This optimization aims at avoiding wasting time and resources to create a new block when one has already been created and validated by a quorum of provisioners.

This optimization is to be thoroughly discussed to determine if a safe and efficient design is indeed possible.
Also, this is to be tackled in the future and is NOT A PRIORITY in this moment.

Additional context

With the introduction of the Ratification phase, we might have a successful Validation (ie, one that reaches a quorum of votes) that fails to be ratified due to network latency or ghost provisioners. When this occurs, it is wasteful to discard an already validated block. Instead, we could have the same block ratified by a different Ratification committee.

Possible solution design or implementation

There are two possible approaches for this optimization.

One approach is to terminate the current Iteration and start a new one with the same block.
In this case, the new Block Generator should re-propose the same block. Since this block is already known it doesn't need to be re-validated, so the Validation phase can be skipped and a second Ratification phase is done (with a new committee).

Another approach would be to keep working on the same Iteration and simply perform a new Ratification phase with a different committee.

Concerns

Both approaches have theoretical and implementation difficulties to be solved.

For instance, for a block to be re-proposed, its hash must be independent from the round and iteration (which are currently included in the block structure and then determine the block hash).

Another issue is the block reward, which is currently assigned to the block generator: each generator produces a different state, and hence a different block hash, preventing such a block to be reused.
A possible solution to this would be to assign the block reward in the next block. By doing so, the block hash would be the same regardless of its producer.

Generally speaking, it is unclear if any of these approaches is actually safe in terms of forks.
A thorough discussion is then required for this improvement to be implemented.