staking: reverse causality of rate calculations

[hdevalence]

Is your feature request related to a problem? Please describe.

Currently, the staking rate calculations are derived from the code that was originally used just to build the exchange rate mechanism and test that it works. As a result, the flow of causality is roughly: fixed base rate → validator exchange rate → (implicitly) change to size of validators' delegation pool.

However, this isn't what we actually want: we want to take the amount of new issuance for a delegation pool as the given input, then compute the validator exchange rate that prices in that change to the delegation pool. This way, we can split apart two responsibilities: (1) the overall tokenomics for staking, which determines the new issuance for each delegation pool [i.e., some new code] and (2) the mechanism that actually does the accounting to track changes to the pool size [i.e., the validator rate mechanism]

For instance, this allows us to implement #1450, because we can (a) compute the new staking issuance for each delegation pool and then (b) add in the fees collected by that validator before (c) computing a validator exchange rate that prices in a+b.

It will also allow us to implement variable staking rewards, or variable splits of newly issued tokens between stakers or other streams, since those just change the "top" of the pipe.

Describe the solution you'd like

• Create a new piece of code that determines the new staking issuance for each validator's delegation pool at the end of the epoch (to start, this can use a fixed inflation rate, like we do currently);
• Refactor the validator exchange rate computations introduced in staking: refactor and clean up staking rate calculations #1480 to take an amount of new issuance as the input, and the validator exchange rate as the output.

[hdevalence]

The new piece of code could be called "distributions", along the lines of the Cosmos SDK's distributions module.

[conorsch]

Kicking back to Next, and unassigning @plaidfinch. Optimistically, @erwanor will pick this up for 64.

[erwanor]

The causality reversal is completed in #3415. The refactor and clean-up are tracked in #1480.