IF: Unification: Deprecate proposal and new_block messages

[arhag]

We do not need the new_block message anymore. Just get rid of it.

Remove proposal network message and instead generate a proposal to incorporate into qc_chain by generating one from the signed_block network message. We need to extract the relevant proposal information from the signed_block. Right now all that is needed is proposal it builds off of. This can be identified using the previous field of the signed_block. We can have the proposal ID be the block ID now to make this identification easy.

EDIT: We don't need to remove the proposal network message as part of this issue since we will make more significant changes soon that makes that work obsolete.

[fcecin]

Part 1/2 of this issue (remove new block message) is addressed by #1919

For part 2/2 (remove proposal message), my current idea is:

• Remove message propagation from qc_chain::process_proposal, since it is no longer a network message
• Change test_pacemaker to not require hs_proposal_message multi-hop propagation (do what was being done for the now defunct hs_new_block_message)

This guarantees that the unit tests keep working with minimal modifications (since the unit tests don't have signed_block, so they will keep using hs_proposal_message internally to emulate it, at least for now).

Then:

• Produce a hs_proposal_message structure anywhere in e.g. net_plugin and pass it to the chain_pacemaker (e.g. when a signed_block is received, or at any time when a new proposal is supposed to be modeled inside of the qc_chain)
• Remove qc_chain::on_beat() (no longer needed; instead the production of a signed_block locally is no different than receiving a signed_block from a remote producer)

Does this look like a good idea?

[linh2931]

It sounds good. Shoud _message be dropped from hs_proposal_message in the structure's name?

[fcecin]

It sounds good. Shoud _message be dropped from hs_proposal_message in the structure's name?

I'm fiddling with this here and I think it is still called a "message", as that's how it's used in the unit tests. I am not sure if this struct is what's actually sent to the qc_chain in some callback. It is possible we don't even have to mention this struct outside of the hotstuff library, and instead you send something else (either some flat parameters in the callback notifying of a new signed_block being produced or received, or we send in some other structure that we could name hs_proposal for example. But I'm not sure at this point. So for now I'm leaving it as-is.

I think that after the prototype, the unit tests are going to change significantly. I am not sure we will be emulating the network in unit tests going forward. My instinct would be to write tests of the "integration" type, that is, start multiple nodeos processes to test networking. For this to work with IF we may need to expose some extra test APIs. But that would allow us to wipe all these messaging concepts that we are keeping in the prototype to ensure the whole thing can be validated very quickly and we can iterate fast (all the unit tests take 3 seconds to run).

[arhag]

#1919 is sufficient to close this issue. #1929 is no longer needed.