Apply updated configuration to Zeitgeist runtime

[sea212]

Closes #595

This PR essentially applies the configuration as discussed in issue #595 . To be able to configure different values for the Zeitgeist pallet within the different runtimes, it was necessary to move the parameters from the primitives crate into the runtime-* crate. Since all mocks relied on the constants defined in the primitives crate, the primitives::constants module was extended by a mock module which contains all those constants.

The configuration values for the parachain-staking pallet were not applied. This is due to the fact that the implications of changing them are unknown yet. We need more time to figure out what the implications are and which migrations we'll have to execute. Issue #751 reflects that.

In regards to implications, changing the bonds for the prediction markets pallet could lead to problems, but since no prediction markets exist on the mainnet before we will apply those changes, we don't have to worry about this.

[maltekliemann]

Looks fine. 👍

I wonder if we should organize this a little differently, though. Maybe I'm just not used to this setup, but it starts seeming quite complex. Maybe we should accept a certain degree of code duplication in favor of some clearner imports/cargo.toml files.

(I don't have a clean plan for this, just thinking on the spot)

[maltekliemann]

Suggested change

	/// The reserve ID of the court pallet.
	/// The reserve ID of the prediction-markets pallet.

[sea212]

Mitigated in 587e90e

[Chralt98]

👍 Love the comments for the runtime constants.

[sea212]

I wonder if we should organize this a little differently, though. Maybe I'm just not used to this setup, but it starts seeming quite complex. Maybe we should accept a certain degree of code duplication in favor of some clearner imports/cargo.toml files.

This is definitely a drawback that's not nice at all. We copy the code from the common crate to the runtime crates, but the imports are required in the runtime crates. One does not see directly why those imports are necessary. I am open to change it, I'd label it low priority though since for now it works and only minor changes are necessary to add new stuff.

[sea212]

I wonder if we should organize this a little differently, though. Maybe I'm just not used to this setup, but it starts seeming quite complex. Maybe we should accept a certain degree of code duplication in favor of some clearner imports/cargo.toml files.

This is definitely a drawback that's not nice at all. We copy the code from the common crate to the runtime crates, but the imports are required in the runtime crates. One does not see directly why those imports are necessary. I am open to change it, I'd label it low priority though since for now it works and only minor changes are necessary to add new stuff.

Let's keep it like it is for a couple of weeks and see how we feel about that after that time.