feat!: use gossipsub for consensus broadcasts

[mrnaveira]

Description

• Both the mempool and HotStuff send broadcast messages using the same gossipsub infrastructure.
• The networking layer allows to specify a map (tx_gossip_messages_by_topic) that maps topic prefixes to a channel. On startup we register a channel for mempool (topic prefix transactions) and another for consensus (topic prefix consensus). Then, on gossip message received, the networking layer simply relays it to the appropriate channel based on the topic prefix. This design allows us to easily use gossip for other purposes in the future.
• Message encoding and decoding is done in each service (mempool or consensus) separately.
• New ConsensusGossipService in the Validator node, that listens for epoch events and subscribes to the appropriate gossip topics. It also does message encoding/decoding.
• Updated the MempoolGossip module to adapt it to the new gossip design, by implementing message encoding/decoding and to receive the messages from networking.
• The consensus layer is independent of how communication is done.
  • ConsensusInboundMessaging now also listens to consensus messages coming from the new ConsensusGossipService .
  • ConsensusOutboundMessaging uses the new ConsensusGossipService for broadcasting.
  • The OutboundMessaging trait for the multicast function now expects a ShardGroup instead of a committee.

Motivation and Context

Hotstuff and cerberus are message based protocols. Currently we implement a message protocol that requires nodes to connect to every other node in the local shard. For cross shard messaging, we implement a strategy that limits the number of messages sent but relies on multiple connections per peer across shards.

We want to leverage libp2p's gossipsub for all consensus broadcasts to local/foreign shards.

• Each shard subscribes to their topic consensus-{start}-{end} (start and end are the start/end shards in the ShardGroup type, similar to the mempool service)
• Ambient peer discovery required by gossipsub is already performed by the Tari-implemented peer sync protocol and L1 registrations

How Has This Been Tested?

Manually by starting a local network using tari_spawn, performing transactions and inspecting the logs.

What process can a PR reviewer use to test or verify this change?

See previous section

Breaking Changes

• [ ] None
• [ ] Requires data directory to be deleted
• [x] Other - Requires network reset, as multicast communications between VNs are now done via gossip

[github-actions[bot]]

Test Results (CI)

570 tests  ±0   569 :white_check_mark: ±0   3h 14m 37s :stopwatch: - 21m 42s  64 suites ±0     0 :zzz: ±0    2 files   ±0     1 :x: ±0 

For more details on these failures, see this check.

Results for commit ba313103. ± Comparison against base commit 3ecc6713.

:recycle: This comment has been updated with latest results.