Staking pallet

[kayabaNerve]

Right now, consensus is wired to use session, yet the validators are unweighted. staking looks suitable to me, so this issue is two fold:

1. Integrate staking into tendermint
2. Integrate staking into Serai

The former refers to the tendermint pallet and providing weight data to the machine. The latter refers to being able to stake within Serai.

[kayabaNerve]

I believe this also includes supporting slashing as I believe that's offered via staking.

[kayabaNerve]

Immediately, slashing at least needs to be moved to a return as right now, losing any validator can cause all validators to crash.

[kayabaNerve]

It now prints an error message and returns.

[kayabaNerve]

Reviewing the staking pallet, we can use:

• Stake
• DPoS (which relates to Delegated PoS #55)
• Slash

Can't use:

• Session management code. Our plan is for a staking pallet, yet then stakers join validator sets. It's validators in sets which participate in Tendermint (at least, under our current designs. In the long term, this may change in the name of scalability).
• Rewards. It rewards its idea of a session, not what we'll have for sessions. We can probably use its rewards calculation code, just not its distribution code.
• Unstake. It sets its own unstake policies, yet Serai sessions don't end at the end of their epoch. They end at the end of their epoch AND when the multisig is no longer active.

I talked with @TheArchitect108 and I'll put forth a minimal staking pallet. Then I'll continue work on the validator-sets branch.

[kayabaNerve]

https://github.com/serai-dex/serai/tree/staking has a pallet offering Stake, DPoS (technically. You can't undelegate from an active validator, forcing them to churn out, making it decently unsafe), and Unstake. It still needs:

• Slashing
• Session management

Rewards will probably be done elsewhere for us.

To be a bit more elaborate on slashing, there's two ways to do so.

1. If verifiable, use inherent transactions under consensus.
2. If observable, collect votes.

The latter is far more inefficient, yet also more comprehensive. We slash if a validator fails to propose. We can't create a permanent, cryptographic proof of them being malicious there. Accordingly, we need the latter. Since we need the latter,, it can be the only option we do. Then all events which could be under the former can just be under the latter for now.

[kayabaNerve]

Slashing will be moved to #164.

[kayabaNerve]

TODO:

• Add an event
• Calculate weights
• Session management
• Have it track who allocates/deallocates as a layer of defense

[kayabaNerve]

Closing a dated issue with merging of initial pallet in #373.