Approval Voting improvements (#2781)

* extract database from av-store itself

* generalize approval-voting over database type

* modes (without handling) and pruning old wakeups

* rework approval importing

* add our_approval_sig to ApprovalEntry

* import assignment

* guide updates for check-full-approval changes

* some aux functions

* send messages when becoming active.

* guide: network bridge sends view updates only when done syncing

* network bridge: send view updates only when done syncing

* tests for new network-bridge behavior

* add a test for updating approval entry with sig

* fix some warnings

* test load-all-blocks

* instantiate new parachains DB

* fix network-bridge empty view updates

* tweak

* fix wasm build, i think

* Update node/core/approval-voting/src/lib.rs

Co-authored-by: Andronik Ordian <write@reusable.software>

* add some versioning to parachains_db

* warnings

* fix merge changes

* remove versioning again

Co-authored-by: Andronik Ordian <write@reusable.software>

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

@@ -60,6 +60,7 @@ 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,
 }
@@ -205,7 +206,7 @@ On receiving a `ApprovalVotingMessage::CheckAndImportAssignment` message, we che
     * Ensure the validator index is not present in the approval entry already.
     * Create a tranche entry for the delay tranche in the approval entry and note the assignment within it.
     * Note the candidate index within the approval entry.
-  * [Check for full approval of the candidate entry](#check-full-approval) of the candidate_entry, filtering by this specific approval entry.
+  * [Schedule a wakeup](#schedule-wakeup) for this block, candidate pair.
   * return the appropriate `AssignmentCheckResult` on the response channel.
 
 #### `ApprovalVotingMessage::CheckAndImportApproval`
@@ -232,20 +233,15 @@ On receiving an `ApprovedAncestor(Hash, BlockNumber, response_channel)`:
 ### Updates and Auxiliary Logic
 
 #### Import Checked Approval
-  * Import an approval vote which we can assume to have passed signature checks.
+  * Import an approval vote which we can assume to have passed signature checks and correspond to an imported assignment.
   * Requires `(BlockEntry, CandidateEntry, ValidatorIndex)`
   * Set the corresponding bit of the `approvals` bitfield in the `CandidateEntry` to `1`. If already `1`, return.
-  * [Check full approval of the candidate](#check-full-approval)
-
-#### Check Full Approval
-  * Checks the approval state of the candidate under every block it is included by, and updates the block entries accordingly.
-  * Requires `(CandidateEntry, filter)`, where filter is used to limit which approval entries are inspected.
-  * Checks every `ApprovalEntry` that is not yet `approved` for whether it is now approved.
-    * For each `ApprovalEntry` in the `CandidateEntry` that is not `approved` and passes the `filter`
-    * Load the block entry for the `ApprovalEntry`.
-    * If so, [determine the tranches to inspect](#determine-required-tranches) of the candidate,
-    * If [the candidate is approved under the block](#check-approval), set the corresponding bit in the `block_entry.approved_bitfield`.
+  * Checks the approval state of a candidate under a specific block, and updates the block and candidate entries accordingly.
+  * Checks the `ApprovalEntry` for the block.
+    * [determine the tranches to inspect](#determine-required-tranches) of the candidate,
+    * [the candidate is approved under the block](#check-approval), set the corresponding bit in the `block_entry.approved_bitfield`.
     * Otherwise, [schedule a wakeup of the candidate](#schedule-wakeup)
+  * If the approval vote originates locally, set the `our_approval_sig` in the candidate entry.
 
 #### Handling Wakeup
   * Handle a previously-scheduled wakeup of a candidate under a specific block.

polkadot/roadmap/implementers-guide/src/node/utility/network-bridge.md

@@ -59,6 +59,8 @@ Each network event is associated with a particular peer-set.
 
 The `activated` and `deactivated` lists determine the evolution of our local view over time. A `ProtocolMessage::ViewUpdate` is issued to each connected peer on each peer-set, and a `NetworkBridgeEvent::OurViewChange` is issued to each event handler for each protocol.
 
+We only send view updates if the node has indicated that it has finished major blockchain synchronization. 
+
 If we are connected to the same peer on both peer-sets, we will send the peer two view updates as a result.
 
 ### Overseer Signal: BlockFinalized
@@ -67,7 +69,7 @@ We update our view's `finalized_number` to the provided one and delay `ProtocolM
 
 ### Network Event: Peer Connected
 
-Issue a `NetworkBridgeEvent::PeerConnected` for each [Event Handler](#event-handlers) of the peer-set and negotiated protocol version of the peer. Also issue a `NetworkBridgeEvent::PeerViewChange` and send the peer our current view.
+Issue a `NetworkBridgeEvent::PeerConnected` for each [Event Handler](#event-handlers) of the peer-set and negotiated protocol version of the peer. Also issue a `NetworkBridgeEvent::PeerViewChange` and send the peer our current view, but only if the node has indicated that it has finished major blockchain synchronization. Otherwise, we only send the peer an empty view.
 
 ### Network Event: Peer Disconnected