Introduce upgrade go-ahead and upgrade restriction signals

[pepyakin]

This patch introduces a new mechanism that will be used in future by parachains to apply validation code upgrade.

Currently, the upgrades are assumed to be activated after a fixed number of relay-chain blocks. Also there are configuration values that the parachain should keep an eye on to not signal an upgrade before an upgrade cooldown (aka validation_upgrade_frequency) timer elapses. These mechanics do not work well with our planned changes such as #3211 and paritytech/polkadot-sdk#967.

Thus as a first step to tackle this problem this patch introduces two new signals that should coordinate an upgrade:

• upgrade go ahead signal
• upgrade restriction signal

Instead of counting the number of the relay chain blocks passed since the upgrade was signalled the parachain will be looking at the upgrade go ahead signal through merkle proofs.

The logic of upgrades themselves is not changed at this time.

This signal is almost always absent. However, at the relay-chain block the upgrade expected to happen, this signal will be turned on. When a parachain block is created on top of that relay-parent or it's descendant, it will observe the go ahead signal and enact the upgrade. The next parablock will be validated using the upgraded validation code.

As soon as the first block with the activated upgrade is included, the signal is reset.

The upgrade restriction signal is set when validation code upgrades are disallowed. We do not give details on why at this moment. To follow the current upgrade logic, this signal is set as soon as the upgrade is announced. The signal is unset only after validation_upgrade_frequency is elapsed.

Rationale

Why two signals, it seems that it's possible to get away with only one?

It's indeed was initial thinking that one signal will do.

When I approached this problem I realized that semantically those are different states and cannot be represented by a single state machine. A contrived example: We have a parathread. The parathread doesn't produce blocks too often. The parathread schedules an upgrade. Then the parathread produces a block after validation_upgrade_frequency. If the signal had a single state only we would have to signal GoAhead first. We have to delay signalling that the upgrade is allowed to another relay-block.

Besides being semantically unsound, it was also harder to implement a single signal model.

[rphmeier]

Looks like a welcome refactoring and more elegant solution to the upgrade signal process. Is the plan to migrate Cumulus and eventually phase out some of the other storage members?

[pepyakin]

Yes, this patch is just a stepping stone. My rough plan is:

• merge this
• deploy this on {rococo, kusama}
• merge Look at the upgrade go-ahead and restriction signals cumulus#517 and ask parachains to update their collators
• at this point, I imagine, UpcomingUpgrades won't be needed and will be substituted by another mechanism to signal the GoAhead. E.g. the pre-checking game.

[rphmeier]

LGTM after merge addressed