Minting upgradability about badger-multisig HOT 3 OPEN

@petrovska-petro, given the reach of the contract in matter, Dapp requested that we include a bit more of testing diligence in the script before executing. Specifically, we wants confirmation via a test that the controller and the BADGER token will continue to work properly after the change.

Adding a simulation of a few of the actions on both the controller and the token within the same script (scripts/issue/1277/mint_controller_admin_update.py) will be enough.

from badger-multisig.

Refs:

• transferOwnership. It could transfer it to timelock
• for queueTransaction in the timelock the admin could be a msig where the owners are the folllowing existing msigs: dev_msig, treasury_msig and a new one badger_council_msig
• cap could be introduce one L above this with a require statement check

from badger-multisig.

conclusions from discussion with @dapp-whisperer:

• yes, moving minting func to the timelock makes sense. security policy currently in place for the badger system should also apply to the badger token itself
• broadening the scope of what governance is (ie making treasury also a signer on dev msig, or something similar) is a good convo to have but outside of the scope of the ticket. convo should take place though
• introducing a mint cap again is outside the scope. introducing such a cap would imply a consensus on inflation rate, which needs a bip first or some form of agreement between councils.

tldr: scope of this ticket is therefore reduced to:

• transfer ownership to timelock, so that minting cannot be done atomically

from badger-multisig.