Versioned Parachain Primitives & Upgrade Path

[rphmeier]

For future updates, such as paritytech/polkadot-sdk#967, and paritytech/polkadot-sdk#968 we will need to be able to increase the versions of critical types.

• CandidateDescriptor
• CandidateReceipt
• ValidationParams
• ValidationOutputs
• AvailableData
• Statements, Assignments, Approval Votes, and Dispute Votes
• etc.

We'd also like the property that using one version somewhere implies using the same version for the same parachain block. That is, if a candidate has V1, that the validation params also have V1, and the validation outputs, and the available data. We'll want to expand the checks that the relay chain performs, as well as the checks that the validator itself performs during approval-checking and disputes. The relay-chain should indicate, either by its runtime API version or a specific runtime API dedicated to this purpose, which versions of data it accepts.

I think changing types to have an enum-based format would work well with the codec. However, we may want to use something more complex which provides a more convenient API.

The last thing that we need to consider is that these types aren't currently tagged with versions, which means that they're all implicitly version 1. We need to continue to support version 0 as we migrate to version 2 and so on. I expect that each primitives upgrade should come with an associated protocol upgrade for network protocols. For example, we currently have /polkadot/validation/1, /polkadot/request_chunk/1, and so on. These would migrate to /2, and our subsystems would need to handle multiple protocols and primitive versions gracefully.