feat(code): Implement minimal gossip properties to ensure liveness

[ancazamfir]

Closes: #998

Implement minimal gossip properties for liveness.

Summary of changes

1. Liveness messages:

   • Added a new /liveness topic/ channel and message types for network communication
   • Introduced new protobuf definitions in liveness.proto for handling gossip messages
   • Added support for PolkaCertificate and RoundCertificate message types

2. Network Layer Changes:

   • Added a new Liveness channel type alongside existing channels (Consensus, ProposalParts, Sync)
   • Modified network event handling to distinguish between consensus and liveness messages
   • Updated message encoding/decoding to support the new liveness message types

3. Certificate Handling:

   • Moved PolkaCertificate and related types from sync proto to liveness proto
   • Added new RoundCertificate type for handling round-specific certificates

4. Codec Updates:

   • Added new codec implementations for liveness messages
   • Updated protobuf codec to handle the new message types

Still to be done:
- [ ] Remove vote set mode - done in separate PR #1008
- [ ] Move rebroadcast in its own module and outside core-consensus - will do in separate PR

• Proper verification for gossip messages (in particular the round certificate)
  • Currently verify vote by vote rather than adding new effect and verification in the engine
  • Let's reconsider depending on when chore(code): Move mode check for effect handling in engine #942 lands
• Decide if we store the round certificate when it occurs (i.e. we got f+1 quorum or 2f+1 precommit any) similarly with last_prevote and last_precommit or find the certificate when we enter a round > 0 (current approach)
• Write IT tests

---

PR author checklist

For all contributors

• Reference a GitHub issue
• Ensure the PR title follows the conventional commits spec
• Add a release note in RELEASE_NOTES.md if the change warrants it
• Add an entry in BREAKING_CHANGES.md if the change warrants it

For external contributors

• Maintainers of Malachite are allowed to push changes to the branch

[github-actions]

✅ Semver Check Passed

Great job! All semver violations have been resolved. This PR now complies with semantic versioning rules.

If you made version updates, please ensure that:

• The version in Cargo.toml accurately reflects the nature of your changes
• Any breaking changes are properly documented in BREAKING_CHANGES.md

[codecov]

Codecov Report

Attention: Patch coverage is 74.31421% with 206 lines in your changes missing coverage. Please review.

Project coverage is 77.64%. Comparing base (acc180b) to head (e0c3353).
Report is 2 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##           main     #997       +/-   ##
=========================================
+ Coverage      0   77.64%   +77.64%     
=========================================
  Files         0      159      +159     
  Lines         0    16814    +16814     
  Branches      0    16814    +16814     
=========================================
+ Hits          0    13055    +13055     
- Misses        0     2883     +2883     
- Partials      0      876      +876     

Flag	Coverage Δ
integration	77.45% <74.31%> (?)
mbt	7.92% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[romac]

@ancazamfir I just added a basic integration test, looking good so far :)

[ancazamfir]

@nenadmilosevic95 @romac one last thing, we need to decide on (from the round sync spec):

"Open questions:

• What should be the value we adopt for rebroadcastTimeout?"

[ancazamfir]

I enabled these rebroadcast mode tests in 0d7321e:

restart_with_byzantine_proposer_1_rebroadcast_parts_only
restart_with_byzantine_proposer_1_rebroadcast_proposal_and_parts
restart_with_byzantine_proposer_2_rebroadcast_parts_only
restart_with_byzantine_proposer_2_rebroadcast_proposal_and_parts

They all passed locally, however on CI we get
Error publishing message: InsufficientPeers channel=/liveness

I will disable them again and open an issue to solve the failures in a separate PR (issue #1029)

[ancazamfir]

Also liveness::round_certificate_rebroadcast fails in commit f7bd600. Passes locally.

[nenadmilosevic95]

@nenadmilosevic95 @romac one last thing, we need to decide on (from the round sync spec):

"Open questions:

* What should be the value we adopt for rebroadcastTimeout?"

What is the value that you currently use?

[ancazamfir]

@nenadmilosevic95 @romac one last thing, we need to decide on (from the round sync spec):
"Open questions:

* What should be the value we adopt for rebroadcastTimeout?"

What is the value that you currently use?

I still need to do the change to reflect the round sync proposal. Currently we use the old timeout mechanism. We have two timers, PrevoteRebroadcast with duration equal to the timeout_prevote and, similarly, PrecommitRebroadcast with duration equal to the timeout_precommit. When we enter Prevote state we start the PrevoteRebroadcast timer and if it expires we resend last prevote and precommit. When we enter Precommit state we start the PrecommitRebroadcast timer and we resent the last votes when it expires. In both cases we restart the timer that just expired.
The timer duration does not take into account the deltas.

We will have only one timer as proposed but what should be the duration?

[nenadmilosevic95]

@nenadmilosevic95 @romac one last thing, we need to decide on (from the round sync spec):
"Open questions:

* What should be the value we adopt for rebroadcastTimeout?"

What is the value that you currently use?

I still need to do the change to reflect the round sync proposal. Currently we use the old timeout mechanism. We have two timers, PrevoteRebroadcast with duration equal to the timeout_prevote and, similarly, PrecommitRebroadcast with duration equal to the timeout_precommit. When we enter Prevote state we start the PrevoteRebroadcast timer and if it expires we resend last prevote and precommit. When we enter Precommit state we start the PrecommitRebroadcast timer and we resent the last votes when it expires. In both cases we restart the timer that just expired. The timer duration does not take into account the deltas.

We will have only one timer as proposed but what should be the duration?

What was the motivation to have two timeouts?
By "does not take into account the deltas" you mean that it does not increase as we progress in higher rounds?

[ancazamfir]

What was the motivation to have two timeouts?

It was the initial rebroadcast design that starknet proposed. And (in main) we are sending only the last prevote on PrevoteRebroadcast expiry and the last precommit on PrecommitRebroadcast

[nenadmilosevic95]

LGTM, left some minor comments

[nenadmilosevic95]

LGTM

[romac]

🎉