Explicit Para Lifecycle w/ Upgrades and Downgrades

[shawntabrizi]

This PR introduces an explicit lifecycle tracking for paras within the runtime_parachains::paras module.

Changes to parachains are delayed by a session, and as such, tracking exactly what is happening to a Para ID was not very easy.

This introduces a new storage item ParaLifecycles which tracks the current lifecycle of any known Para Id. This replaces the Parathreads storage item since that data is now redundant.

The possible lifecycle states are as follows:

/// The possible states of a para, to take into account delayed lifecycle changes.
pub enum ParaLifecycle {
	/// Para is new and is onboarding as a Parathread.
	OnboardingAsParathread,
	/// Para is new and is onboarding as a Parachain.
	OnboardingAsParachain,
	/// Para is a Parathread.
	Parathread,
	/// Para is a Parachain.
	Parachain,
	/// Para is a Parathread which is upgrading to a Parachain.
	UpgradingToParachain,
	/// Para is a Parachain which is downgrading to a Parathread.
	DowngradingToParathread,
	/// Parachain is being offboarded.
	OutgoingParathread,
	/// Parachain is being offboarded.
	OutgoingParachain,
}

Additionally, this PR introduces the workflow for upgrading a parathread into a parachain, and downgrading a parachain into a parathread.

This will be used for both the Slots/Auction module (which will perform upgrades/downgrades based on parachain auctions and offboarding slots), and also for swaps between parachains and parathreads.

[rphmeier]

Looks fine but needs a guide change.

With this approach I do want to note that once #2300 is implemented, Upgrade and Downgrade will take at least 2 full sessions but probably 3 or more, whereas really they only need to take at least 1 full session - the important thing is that the Upgrade and Downgrade are irreversibly on-chain during that 1 full session.

However that's not a pattern we expect often so it's fine if it takes longer than necessary.

[shawntabrizi]

This should be ready to review

[gavofyork]

why would the number of bits alter when upgrading/downgrading between parthread and parachain?

[rphmeier]

Every availability core gets its own bit in the bitfield. Parathreads are multiplexed over a fixed number of cores (configured per-session), whereas Parachains each get their own dedicated core. Upgrading from parathread to parachain would alter the amount of availability cores, which would alter the division of validators into groups, which could lead to consensus issues across forks.

[gavofyork]

Seems ok. Would be nice to revisit at a later stage when we're thinking about more exotic scheduling systems (e.g. static slot scheduling where two or more parachains occupy slots in a fixed and repetitive pattern).

[gavofyork]

Would it be convenient to build in parachain/thread swap logic in here now?

[rphmeier]

Would it be convenient to build in parachain/thread swap logic in here now?

@gavofyork In a way, that could be done already with the higher-level code (slots) triggering a downgrade of one and an upgrade of the other.

[shawntabrizi]

@rphmeier @gavofyork yeah, this is what I did in Registrar. A swap is just a scheduled upgrade and downgrade. I think that is granular enough.

[shawntabrizi]

There is more that needs to be updated in future PRs, but this is a reasonable checkpoint i think for the direction we are headed.

Some more notes on what is next here: https://hackmd.io/XDkKzaYMSYumhNWzRMEvCQ