approval-voting improvement: include all tranche0 assignments in one certificate (#1178)

**_PR migrated from https://github.com/paritytech/polkadot/pull/6782_** 

This PR will upgrade the network protocol to version 3 -> VStaging which
will later be renamed to V3. This version introduces a new kind of
assignment certificate that will be used for tranche0 assignments.
Instead of issuing/importing one tranche0 assignment per candidate,
there will be just one certificate per relay chain block per validator.
However, we will not be sending out the new assignment certificates,
yet. So everything should work exactly as before. Once the majority of
the validators have been upgraded to the new protocol version we will
enable the new certificates (starting at a specific relay chain block)
with a new client update.

There are still a few things that need to be done:

- [x] Use bitfield instead of Vec<CandidateIndex>:
https://github.com/paritytech/polkadot/pull/6802
  - [x] Fix existing approval-distribution and approval-voting tests
  - [x] Fix bitfield-distribution and statement-distribution tests
  - [x] Fix network bridge tests
  - [x] Implement todos in the code
  - [x] Add tests to cover new code
  - [x] Update metrics
  - [x] Remove the approval distribution aggression levels: TBD PR
  - [x] Parachains DB migration 
  - [x] Test network protocol upgrade on Versi
  - [x] Versi Load test
  - [x] Add Zombienet test
  - [x] Documentation updates
- [x] Fix for sending DistributeAssignment for each candidate claimed by
a v2 assignment (warning: Importing locally an already known assignment)
 - [x]  Fix AcceptedDuplicate
 - [x] Fix DB migration so that we can still keep old data.
 - [x] Final Versi burn in

---------

Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>
Co-authored-by: Alexandru Gheorghe <alexandru.gheorghe@parity.io>

polkadot/roadmap/implementers-guide/src/node/approval/approval-voting.md

@@ -75,22 +75,27 @@ struct TrancheEntry {
     assignments: Vec<(ValidatorIndex, Tick)>,
 }
 
-struct OurAssignment {
-  cert: AssignmentCert,
-  tranche: DelayTranche,
-  validator_index: ValidatorIndex,
-  triggered: bool,
+pub struct OurAssignment {
+	/// Our assignment certificate.
+	cert: AssignmentCertV2,
+	/// The tranche for which the assignment refers to.
+	tranche: DelayTranche,
+	/// Our validator index for the session in which the candidates were included.
+	validator_index: ValidatorIndex,
+	/// Whether the assignment has been triggered already.
+	triggered: bool,
 }
 
-struct ApprovalEntry {
-    tranches: Vec<TrancheEntry>, // sorted ascending by tranche number.
-    backing_group: GroupIndex,
-    our_assignment: Option<OurAssignment>,
-    our_approval_sig: Option<ValidatorSignature>,
-    assignments: Bitfield, // n_validators bits
-    approved: bool,
+pub struct ApprovalEntry {
+	tranches: Vec<TrancheEntry>, // sorted ascending by tranche number.
+	backing_group: GroupIndex,
+	our_assignment: Option<OurAssignment>,
+	our_approval_sig: Option<ValidatorSignature>,
+	assigned_validators: Bitfield, // `n_validators` bits.
+	approved: bool,
 }
 
+
 struct CandidateEntry {
     candidate: CandidateReceipt,
     session: SessionIndex,
@@ -264,19 +269,25 @@ entry. The cert itself contains information necessary to determine the candidate
   * Check the assignment cert
     * If the cert kind is `RelayVRFModulo`, then the certificate is valid as long as `sample <
       session_info.relay_vrf_samples` and the VRF is valid for the validator's key with the input
-      `block_entry.relay_vrf_story ++ sample.encode()` as described with [the approvals protocol
-      section](../../protocol-approval.md#assignment-criteria). We set `core_index = vrf.make_bytes().to_u32() %
-      session_info.n_cores`. If the `BlockEntry` causes inclusion of a candidate at `core_index`, then this is a valid
-      assignment for the candidate at `core_index` and has delay tranche 0. Otherwise, it can be ignored.
-    * If the cert kind is `RelayVRFDelay`, then we check if the VRF is valid for the validator's key with the input
-      `block_entry.relay_vrf_story ++ cert.core_index.encode()` as described in [the approvals protocol
-      section](../../protocol-approval.md#assignment-criteria). The cert can be ignored if the block did not cause
-      inclusion of a candidate on that core index. Otherwise, this is a valid assignment for the included candidate. The
-      delay tranche for the assignment is determined by reducing `(vrf.make_bytes().to_u64() %
-      (session_info.n_delay_tranches +
-      session_info.zeroth_delay_tranche_width)).saturating_sub(session_info.zeroth_delay_tranche_width)`.
-    * We also check that the core index derived by the output is covered by the `VRFProof` by means of an auxiliary
-      signature.
+      `block_entry.relay_vrf_story ++ sample.encode()` as described with
+      [the approvals protocol section](../../protocol-approval.md#assignment-criteria). We set
+      `core_index = vrf.make_bytes().to_u32() % session_info.n_cores`. If the `BlockEntry` causes
+      inclusion of a candidate at `core_index`, then this is a valid assignment for the candidate
+      at `core_index` and has delay tranche 0. Otherwise, it can be ignored.
+    * If the cert kind is `RelayVRFModuloCompact`, then the certificate is valid as long as the VRF
+      is valid for the validator's key with the input `block_entry.relay_vrf_story ++ relay_vrf_samples.encode()`
+      as described with [the approvals protocol section](../../protocol-approval.md#assignment-criteria).
+      We enforce that all `core_bitfield` indices are included in the set of the core indices sampled from the
+      VRF Output. The assignment is considered a valid tranche0 assignment for all claimed candidates if all
+      `core_bitfield` indices match the core indices where the claimed candidates were included at.
+
+    * If the cert kind is `RelayVRFDelay`, then we check if the VRF is valid for the validator's key with the
+      input `block_entry.relay_vrf_story ++ cert.core_index.encode()` as described in [the approvals protocol
+      section](../../protocol-approval.md#assignment-criteria). The cert can be ignored if the block did not
+      cause inclusion of a candidate on that core index. Otherwise, this is a valid assignment for the included
+      candidate. The delay tranche for the assignment is determined by reducing
+      `(vrf.make_bytes().to_u64() % (session_info.n_delay_tranches + session_info.zeroth_delay_tranche_width)).saturating_sub(session_info.zeroth_delay_tranche_width)`.
+    * We also check that the core index derived by the output is covered by the `VRFProof` by means of an auxiliary signature.
     * If the delay tranche is too far in the future, return `AssignmentCheckResult::TooFarInFuture`.
   * Import the assignment.
     * Load the candidate in question and access the `approval_entry` for the block hash the cert references.