//! This pallet exposes two APIs; one *inbound* side to update parameters, and one *outbound* side
//! to access said parameters. Parameters themselves are defined in the runtime config and will be
//! aggregated into an enum. Each parameter is addressed by a `key` and can have a default value.
//! This is not done by the pallet but through the [`frame_support::dynamic_params::dynamic_params`]
//! Note that this is incurring one storage read per access. This should not be a problem in most
//! The inbound side solely consists of the [`Pallet::set_parameter`] extrinsic to update the value
//! implementation and can be used in every spot where that is accepted. Two macros are in place:
//! This pallet is a good fit for updating parameters without a runtime upgrade. It is very handy to
//! not require a runtime upgrade for a simple parameter change since runtime upgrades require a lot
//! of diligence and always bear risks. It seems overkill to update the whole runtime for a simple
//! The only down-side is that it trades off performance with convenience and should therefore only
//! The pallet will also require a default value for benchmarking. Ideally this is the variant with
//! The pallet stores the parameters in a storage map and implements the matching `Get<Value>` for
//! each `Key` type. The `Get` then accesses the `Parameters` map to retrieve the value. An event is
//! emitted every time that a value was updated. It is even emitted when the value is changed to the
//! enum. This enum is then injected into the pallet. This allows it to be used without any changes
//! 1. Everything is done at runtime without the need for `const` values. `Get` allows for this -
//! which is coincidentally an upside and a downside. 2. The types are defined through macros, which
//! allows to expose metadata and docs. 3. Access control is done through the `EnsureOriginWithArg`