Replace constants with mutables

[bedeho]

Background

Same as this issue: https://github.com/Joystream/joystream/issues/3622

Read it.

Proposal

On further reflection, its not clear that having any value as a constant makes a great deal of sense in the context of an upgradable Substrate chain. We have the ability to do forkless upgrades, and we have a proposal system for that. Those upgrades allow us to change any property of the system, including values of constants. It would be sensible, and seemingly a free lunch, to make it possible to replace constants with storage variables which then could be explicitly changed with proposals, because

1. There is no-net increased risk of accepting a bad change, because the proposal for doing a variable change can be as strict as the proposal for doing a full runtime upgrade.
2. It will be easier for the council to fully understand what change is being proposed when you have specific parameter proposals rather than a blanket runtime upgrade, the latter requires confronting the details of any changes in the Rust codebase. This effectively means we are increasing the social bandwidth of the community by making certain decisions easier to understand, evaluate and deliberate over.
3. There are probably many current constants that def. should not be constants to begin with, just because they are quite low risk to change.

For this reason I suggest we

• remove all constants in the runtime, and replace with mutable storage values. This may require introducing a new parameter storage pallet or something, just to hold values that perhaps don't naturally belong in any one single pallet.
• make sure to introduce a get/set pallet method which allows the proposal system to read/write value.
• make all such pallet storage values configurable, so that it's practical to build the node to run under very different circumstances.

A very large number of new values will come from the proposal system, which heretofore had all ProposalParameters harcoded, and also constraints on input values hardcoded.

[bedeho]

Seems like parameter_types macro actually has the ability to define storage level values stored under a fixed key, so perhaps no new pallet is needed. https://paritytech.github.io/substrate/master/frame_support/macro.parameter_types.html

[bedeho]

On further examination, perhaps having a standalone parameter pallet is better because

• that means we can very conveniently allow specification of all values for a new chain through GenesisConfig for that pallet. It's not a
• it will be easy for our proposal codex to update these values, not sure what sort setters parameter_types will generate, if any. Writing to raw storage keys, under the assumption of how this macro will place the value, is very unattractive.
• if values in pallet GenesisConfig and these other parameters need to be coordinated or compatible in some way, then this will be a much safer way of ensuring this, rather than making it possible for people to inadvertently mix wrong chain spec and node build.

[bedeho]

Replaced by https://github.com/Joystream/joystream/issues/4225.