Shd stake | rewards distribution

[FloppyDisck]

Added an efficient way to distribute value across stakers by using the staking model found in Cosmos SDK.
There are now separate unbonding queues per users so they can query their values efficiently. The old unbonding now exists for when we implement treasury rewards distribution.
To allow users to query their stake information, a very simple viewing key system was implemented

[DrPresident]

We should try to avoid implementing anything with keys/passwords in our contracts. Thats alot of liability and complexity to take on in order to do it right, and anything less would be facade of security that would be detrimental to having none at all. We should be using a snip20 for the staked tokens for this and I believe the permits solve the issue of governance being able to determine voting power.

[FloppyDisck]

We should try to avoid implementing anything with keys/passwords in our contracts. Thats alot of liability and complexity to take on in order to do it right, and anything less would be facade of security that would be detrimental to having none at all. We should be using a snip20 for the staked tokens for this and I believe the permits solve the issue of governance being able to determine voting power.

While having a snip20 does make it a bit easier since you dont have to implement secret_toolkit's permits, it would also increase all around gas costs for the staking contract, plus add a few more failure points (allowed minters + another contract). A much more efficient way would be to directly implement permits into the staking contract.

Furthermore, viewkeys / permits are not the point of this PR and are going to be implemented after this PR

[chris-ricketts]

Just a couple of nit picks and some Rust tricks you could use if you wanted.
The unbonding mechanics look sound and efficient.