版本化副链原语与升级路径

对于未来的更新，例如 paritytech/polkadot-sdk#967 和 paritytech/polkadot-sdk#968，我们需要能够提高关键类型的版本。 * CandidateDescriptor * CandidateReceipt * ValidationParams * ValidationOutputs * AvailableData * 语句、赋值、批准投票和争议投票 * 等等。 我们还希望具有这样的属性：在某个地方使用一个版本意味着对相同的链上块使用相同的版本。也就是说，如果候选人具有 V1，则验证参数也具有 V1，验证输出也具有 V1，可用数据也具有 V1。我们将需要扩展中继链执行的检查以及验证器本身在批准检查和争议期间执行的检查。中继链应通过其运行时 API 版本或专门用于此目的的特定运行时 API 指示其接受的数据版本。 我认为将类型改为基于枚举的格式将与编码器兼容。然而，我们可能希望使用更复杂的方式，以提供更方便的 API。 我们需要考虑的最后一件事是，这些类型目前没有标记版本，这意味着它们都隐含地具有版本 1。我们需要继续支持版本 0，因为我们迁移到版本 2 等。我预计每个原语升级都将伴随相关的网络协议升级。例如，目前我们有 `/polkadot/validation/1`、`/polkadot/request_chunk/1` 等。这些将迁移到 `/2`，我们的子系统需要优雅地处理多个协议和原语版本。