Add assignment keys to session keys, no separate approvals key (#2092)

* guide: merge backing and approval keys

* bump substrate master & update primitives

* use new SessionInfo struct in session_info

* session keys upgrade for Polkadot

* kusama & westend runtimes

* bump westend, kusama, and polkadot versions

* add session key to rococo & test-runtime

* update prepare-test-net to latest subkey

* update chain specs to support new para_assignment session key

* get cargo.lock from master

* formatting

* update kill_storage based on substrate master

* fix test-service

* assgn -> asgn

* use session info module for assignment session key

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

@@ -281,5 +281,5 @@ enum RequiredTranches {
   * Fetch the block entry and candidate entry. Ignore if `None` - we've probably just lost a race with finality.
   * Construct a `SignedApprovalVote` with the validator index for the session.
   * `import_checked_approval(block_entry, candidate_entry, validator_index)`
-  * Construct a `IndirectSignedApprovalVote` using the informatio about the vote.
+  * Construct a `IndirectSignedApprovalVote` using the information about the vote.
   * Dispatch `ApprovalDistributionMessage::DistributeApproval`.

polkadot/roadmap/implementers-guide/src/protocol-approval.md

@@ -38,7 +38,7 @@ We need two separate keys for the approval subsystem:
 
 - **Approval assignment keys** are sr25519/schnorrkel keys used only for the assignment criteria VRFs.  We implicitly sign assignment notices with approval assignment keys by including their relay chain context and additional data in the VRF's extra message, but exclude these from its VRF input.  
 
-- **Approval vote keys** would only sign off on candidate parablock validity and has no natural key type restrictions.  We could reuse the ed25519 grandpa keys for this purpose since these signatures control access to grandpa, although distant future node configurations might favor separate roles.
+- **Approval vote keys** would only sign off on candidate parablock validity and has no natural key type restrictions. There's no need for this to actualy embody a new session key type. We just want to make a distinction between assignments and approvals, although distant future node configurations might favor separate roles. We re-use the same keys as are used for parachain backing in practice.
 
 Approval vote keys could relatively easily be handled by some hardened signer tooling, perhaps even HSMs assuming we select ed25519 for approval vote keys.  Approval assignment keys might or might not support hardened signer tooling, but doing so sounds far more complex.  In fact, assignment keys determine only VRF outputs that determine approval checker assignments, for which they can only act or not act, so they cannot equivocate, lie, etc. and represent little if any slashing risk for validator operators. 
 

polkadot/roadmap/implementers-guide/src/runtime/session_info.md

@@ -8,12 +8,13 @@ Helper structs:
 
 ```rust
 struct SessionInfo {
-    // validators in canonical ordering.
+    // validators in canonical ordering. These are the public keys used for backing,
+    // dispute participation, and approvals.
     validators: Vec<ValidatorId>,
     // validators' authority discovery keys for the session in canonical ordering.
     discovery_keys: Vec<DiscoveryId>,
-    // The assignment and approval keys for validators.
-    approval_keys: Vec<(AssignmentId, ApprovalId)>,
+    // The assignment keys for validators.
+    assignment_keys: Vec<AssignmentId>,
     // validators in shuffled ordering - these are the validator groups as produced
     // by the `Scheduler` module for the session and are typically referred to by
     // `GroupIndex`.

polkadot/roadmap/implementers-guide/src/types/approval.md

@@ -1,9 +1,5 @@
 # Approval Types
 
-## ApprovalId
-
-The public key of a keypair used by a validator for approval voting on included parachain candidates.
-
 ## AssignmentId
 
 The public key of a keypair used by a validator for determining assignments to approve included parachain candidates.
@@ -57,11 +53,13 @@ struct ApprovalVote(Hash);
 
 ## SignedApprovalVote
 
+An approval vote signed with a validator's key. This should be verifiable under the `ValidatorId` corresponding to the `ValidatorIndex` of the session, which should be implicit from context.
+
 ```rust
 struct SignedApprovalVote {
     vote: ApprovalVote,
     validator: ValidatorIndex,
-    signature: ApprovalSignature,
+    signature: ValidatorSignature,
 }
 ```
 
@@ -78,7 +76,7 @@ struct IndirectSignedApprovalVote {
     // The index of the candidate in the list of candidates fully included as-of the block.
     candidate_index: u32,
     validator: ValidatorIndex,
-    signature: ApprovalSignature,
+    signature: ValidatorSignature,
 }
 ```