Network Bridge Refactoring (#1535)

* rename protocol ID to network capability

* guide: `ProtocolId` -> `NetworkCapability`

* guide: remove `RegisterEventProducer`

* capabilities and expand on underlying network assumptions

* guide: create network.md types file

* guide: network bridge is aware of network messages

* revert changes in code

* Update roadmap/implementers-guide/src/SUMMARY.md

Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>

* remove references to NetworkCapability

* Update roadmap/implementers-guide/src/types/network.md

Co-authored-by: Sergei Shulepov <sergei@parity.io>

Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
Co-authored-by: Sergei Shulepov <sergei@parity.io>

polkadot/roadmap/implementers-guide/src/node/availability/availability-distribution.md

@@ -6,24 +6,21 @@ After a candidate is backed, the availability of the PoV block must be confirmed
 
 ## Protocol
 
-`ProtocolId`:`b"avad"`: `PeerSet`: `Validation`
+`PeerSet`: `Validation`
 
 Input:
 
-- NetworkBridgeUpdate(update)
+- NetworkBridgeUpdateV1(update)
 
 Output:
 
-- NetworkBridge::RegisterEventProducer(`ProtocolId`)
-- NetworkBridge::SendMessage(`[PeerId]`, `ProtocolId`, `Bytes`)
+- NetworkBridge::SendValidationMessage(`[PeerId]`, message)
 - NetworkBridge::ReportPeer(PeerId, cost_or_benefit)
 - AvailabilityStore::QueryPoV(candidate_hash, response_channel)
 - AvailabilityStore::StoreChunk(candidate_hash, chunk_index, inclusion_proof, chunk_data)
 
 ## Functionality
 
-Register on startup an event producer with  `NetworkBridge::RegisterEventProducer`.
-
 For each relay-parent in our local view update, look at all backed candidates pending availability. Distribute via gossip all erasure chunks for all candidates that we have to peers.
 
 We define an operation `live_candidates(relay_heads) -> Set<CommittedCandidateReceipt>` which returns a set of [`CommittedCandidateReceipt`s](../../types/candidate.md#committed-candidate-receipt) a given set of relay chain heads that implies a set of candidates whose availability chunks should be currently gossiped. This is defined as all candidates pending availability in any of those relay-chain heads or any of their last `K` ancestors. We assume that state is not pruned within `K` blocks of the chain-head.

polkadot/roadmap/implementers-guide/src/node/availability/bitfield-distribution.md

@@ -4,22 +4,21 @@ Validators vote on the availability of a backed candidate by issuing signed bitf
 
 ## Protocol
 
-`ProtocolId`: `b"bitd"`: `PeerSet`: `Validation`
+`PeerSet`: `Validation`
 
 Input:
 [`BitfieldDistributionMessage`](../../types/overseer-protocol.md#bitfield-distribution-message) which are gossiped to all peers, no matter if validator or not.
 
 Output:
 
-- `NetworkBridge::RegisterEventProducer(ProtocolId)` in order to register ourself as an event provider for the protocol.
-- `NetworkBridge::SendMessage([PeerId], ProtocolId, Bytes)` gossip a verified incoming bitfield on to interested subsystems within this validator node.
+- `NetworkBridge::SendValidationMessage([PeerId], message)` gossip a verified incoming bitfield on to interested subsystems within this validator node.
 - `NetworkBridge::ReportPeer(PeerId, cost_or_benefit)` improve or penalize the reputation of peers based on the messages that are received relative to the current view.
 - `ProvisionerMessage::ProvisionableData(ProvisionableData::Bitfield(relay_parent, SignedAvailabilityBitfield))` pass
   on the bitfield to the other submodules via the overseer.
 
 ## Functionality
 
-This is implemented as a gossip system. Register a [network bridge](../utility/network-bridge.md) event producer on startup.
+This is implemented as a gossip system.
 
 It is necessary to track peer connection, view change, and disconnection events, in order to maintain an index of which peers are interested in which relay parent bitfields.