Add fast-runtime Cargo Feature for Quick Test Runs

[apopiak]

This is meant as a first stab at making certain runtime configuration values configurable via feature flag.
This PR:

• introduces the fast-runtime feature flag to toggle at build time whether the production or fast/testing values should be used for configuration values like the session time.
• introduces the prod_or_fast macro to easily define config values taking advantage of the fast-runtime flag.
• adjusts a lot of durations down to 2 minutes = 20 blocks, 1 minute = 10 blocks or 1 block (if the feature is selected).
• also introduces environment variables that can be set at build time to specify custom periods (if the feature is selected).

Usage

So to take advantage of the features introduced here you might call cargo like so:

KSM_EPOCH_DURATION=40 KSM_LAUNCH_PERIOD=3 cargo build --release --features=fast-runtime

or with cargo remote:

cargo remote -c release/polkadot -b 'KSM_LAUNCH_PERIOD=2; DOT_LAUNCH_PERIOD=2' -- build --release --features=fast-runtime

Kusama values are prefixed with KSM, Polkadot values with DOT.

Motivation

This allows for easier local testing of the interaction between the production chains with parachains (e.g. Kusama and Statemine).

aims to make progress towards #4333

[apopiak]

I tried parsing a const out of an env variable with

core::option_env!("ENV")
  .map(|s| s.parse().ok())
  .flatten()
  .unwrap_or(default)

but failed because parse is not const. Open to ideas on how we could add something equivalent.

[kianenigma]

I tried parsing a const out of an env variable with

core::option_env!("ENV")
  .map(|s| s.parse().ok())
  .flatten()
  .unwrap_or(default)

but failed because parse is not const. Open to ideas on how we could add something equivalent.

If you need const for parameter types, it does support non-const as well.

[apopiak]

If you need const for parameter types, it does support non-const as well.

Mmh, but would we be comfortable with making it non-const in production for the test usecase?

[kianenigma]

If you need const for parameter types, it does support non-const as well.

Mmh, but would we be comfortable with making it non-const in production for the test usecase?

I am pretty comfortable with both, as long as there's no unreasonable shenanigans going on. Somethings are hard to make 'const', event though they are constant in reality. For example, see Type BlockWeights in system.

[kianenigma]

LGTM

[apopiak]

I think another alternative implementation here is to just have the macro apply some constant reduction to all the constants than defining both.

So having fast-runtime divides any macro wrapped value by 1_000 or an environment variable amount.

Not at flexible, but probably just as useful with less code.

This would definitely only work for very few values. E.g. launch period can be reduced to 1 block without issues, but the election workers need enough time to submit their solutions (5 blocks (2min session time / 4) seems to work, didn't figure out the lower bound).
I much prefer the approach in this PR.

[gilescope]

LGTM

[crystalin]

How about disabling the UnexpectedEpochChange also with it ? It is quite common for test network to get stuck by it

[gilescope]

I take your point but talking with a few people it sounds like there should be a separate feature that turns on settings that make things more robust in terms of max finality lag and max backoffs. This is purely timings, but features are designed to be additive so I think they would play well together.

[gilescope]

bot merge