Introduce compounder cap

[dusan-maksimovic]

Description

This PR introduces the "compounder cap" which reserves certain amount of tokens (out of the total number of tokens allowed to be locked) and allows users that had voting power in previous round to exclusively lock in this cap, for a certain time frame. The "compounder cap" is meant to be active for some time at the beginning of the round. After this time has expired, any amount of tokens that wasn't locked by the compunders will be at disposal to any other user to freely lock, up to the limit of total cap, that is enforced at any time. Implementation also supports re-activation of "compunders cap" at any time during the round, which is controlled by the contract governance and handled by the update_config() action (as it is the case with initial activation).

Techinical Details

Updated contract stores:

• CONSTANTS are converted into Map, to allow different configurations activation depending on the time. This allows us to e.g. prepare 2 configurations- one that increases total_cap and activates the compunder cap, and the other one that is activated some time after and sets the compounder cap to zero.
• LOCKS_MAP converted to SnapshotMap so that we can compute users voting power at a given height. This goes along with newly added storage USER_LOCKS which allows us to know which lockups user had at a given height, since we can not iterate over LOCKS_MAP at desired height in the past.

Newly added stores:

• EXTRA_LOCKED_TOKENS_ROUND_TOTAL and EXTRA_LOCKED_TOKENS_CURRENT_USERS allow us to track how many tokens were locked in compunder cap and enforce the maximum limit per user and in total.
• TOTAL_VOTING_POWER_PER_ROUND stores total voting power for current and all future rounds in which there is at least some voting power. It gets updated each time user locks/relocks as well as on validator power ratio changes. This store will be more useful for governance but it is introduced together with user voting power snapshot map. For compunder cap PR, we could compute this value for past rounds on the fly since we store locked shares and validator power ratios per round, but this is also a bit more performant.
• ROUND_TO_HEIGHT_RANGE and HEIGHT_TO_ROUND are introduced to be able to this conversion, where for the compounder cap we need round->height, while for the governance we will need the other direction. Both stores are updated on each transaction that gets executed against the smart contract. The function for getting round for height will be implemented in governance PR.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Targeted the correct branch
• Included the necessary unit tests
• Added/adjusted the necessary interchain tests
• Added a changelog entry in .changelog
• Compiled the contracts by using make compile and included content of the artifacts directory into the PR
• Regenerated front-end schema by using make schema and included generated files into the PR
• Updated the relevant documentation or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed

[dusan-maksimovic]

This is to support denom resolution for the past rounds. We need to pass in the round_id because sometimes this function gets executed in current round, but we are interested for past rounds (e.g. for compounder cap to determine users voting power in previous round).

[p-offtermatt]

Suggested change

	// the begining of the round, and such Constants would apply only for predefined period of time.
	// the begining of the round, and such Constants would apply only for a predefined period of time.