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/protocol-approval.md

@@ -189,9 +189,10 @@ Assignment criteria compute actual assignments using stories and the validators'
 Assignment criteria output a `Position` consisting of both a `ParaId` to be checked, as well as a precedence
 `DelayTranche` for when the assignment becomes valid.
 
-Assignment criteria come in three flavors, `RelayVRFModulo`, `RelayVRFDelay` and `RelayEquivocation`.  Among these, both
-`RelayVRFModulo` and `RelayVRFDelay` run a VRF whose input is the output of a `RelayVRFStory`, while `RelayEquivocation`
-runs a VRF whose input is the output of a `RelayEquivocationStory`.
+Assignment criteria come in four flavors, `RelayVRFModuloCompact`, `RelayVRFDelay`, `RelayEquivocation` and the
+deprecated `RelayVRFModulo`.  Among these, `RelayVRFModulo`, `RelayVRFModuloCompact` and `RelayVRFDelay` run a
+VRF whose input is the output of a `RelayVRFStory`, while `RelayEquivocation` runs a VRF whose input is the
+output of a `RelayEquivocationStory`.
 
 Among these, we have two distinct VRF output computations:
 
@@ -203,6 +204,12 @@ sampled availability core in this relay chain block.  We choose three samples in
 secure and efficient by increasing this to four or five, and reducing the backing checks accordingly.  All successful
 `RelayVRFModulo` samples are assigned delay tranche zero.
 
+`RelayVRFModuloCompact` runs a single samples whose VRF input is the `RelayVRFStory` and the sample count. Similar
+to `RelayVRFModulo` introduces multiple core assignments for tranche zero. It computes the VRF output with
+`schnorrkel::vrf::VRFInOut::make_bytes` using the context "A&V Core v2" and samples up to 160 bytes of the output
+as an array of `u32`. Then reduces each `u32` modulo the number of availability cores, and outputs up
+to `relay_vrf_modulo_samples` availability core indices.
+
 There is no sampling process for `RelayVRFDelay` and `RelayEquivocation`.  We instead run them on specific candidates
 and they compute a delay from their VRF output.  `RelayVRFDelay` runs for all candidates included under, aka declared
 available by, a relay chain block, and inputs the associated VRF output via `RelayVRFStory`.  `RelayEquivocation` runs
@@ -223,14 +230,14 @@ We track all validators' announced approval assignments for each candidate assoc
 tells us which validators were assigned to which candidates.
 
 We permit at most one assignment per candidate per story per validator, so one validator could be assigned under both
-the `RelayVRFDelay` and `RelayEquivocation` criteria, but not under both `RelayVRFModulo` and `RelayVRFDelay` criteria,
-since those both use the same story.  We permit only one approval vote per candidate per validator, which counts for any
-applicable criteria.
+the `RelayVRFDelay` and `RelayEquivocation` criteria, but not under both `RelayVRFModulo/RelayVRFModuloCompact`
+and `RelayVRFDelay` criteria, since those both use the same story.  We permit only one approval vote per candidate per
+validator, which counts for any applicable criteria.
 
 We announce, and start checking for, our own assignments when the delay of their tranche is reached, but only if the
-tracker says the assignee candidate requires more approval checkers.  We never announce an assignment we believe
-unnecessary because early announcements gives an adversary information.  All delay tranche zero assignments always get
-announced, which includes all `RelayVRFModulo` assignments.
+tracker says the assignee candidate requires more approval checkers.  We never announce an assignment we believe unnecessary
+because early announcements gives an adversary information.  All delay tranche zero assignments always get announced,
+which includes all `RelayVRFModulo` and `RelayVRFModuloCompact` assignments.
 
 In other words, if some candidate `C` needs more approval checkers by the time we reach round `t` then any validators
 with an assignment to `C` in delay tranche `t` gossip their send assignment notice for `C`, and begin reconstruction and
@@ -318,10 +325,10 @@ finality.  We might explore limits on postponement too, but this sounds much har
 
 ## Parameters
 
-We prefer doing approval checkers assignments under `RelayVRFModulo` as opposed to `RelayVRFDelay` because
-`RelayVRFModulo` avoids giving individual checkers too many assignments and tranche zero assignments benefit security
-the most.  We suggest assigning at least 16 checkers under `RelayVRFModulo` although assignment levels have never been
-properly analyzed.
+We prefer doing approval checkers assignments under `RelayVRFModulo` or `RelayVRFModuloCompact` as opposed to
+`RelayVRFDelay` because `RelayVRFModulo` avoids giving individual checkers too many assignments and tranche zero
+assignments benefit security the most.  We suggest assigning at least 16 checkers under `RelayVRFModulo` or
+`RelayVRFModuloCompact` although assignment levels have never been properly analyzed.
 
 Our delay criteria `RelayVRFDelay` and `RelayEquivocation` both have two primary paramaters, expected checkers per
 tranche and the zeroth delay tranche width.