simulate then upgrade: version 1 to version 2 migrations

[0xekez]

i propose we build a proposal module that when added to a DAO automatically performs an upgrade of that DAO and removes itself. this can be done using the module instantiation callback added by Meow. this module can perform state queries before and after migration and roll back the transaction if an invalid state is encountered. with this, only a single message is required to be executed to migrate a DAO.

in this way we simulate the migration, confirm it worked, and if it did commit the simulation.

let voting_power = query_voting_power(dao, addr);
let total_power = query_total_power(dao);
let proposal_count = query_proposal_count(dao);
let proposal_one = query_proposal(dao, 1);

migrate();

assert_eq(query_voting_power(dao, addr), voting_power);
assert_eq(query_total_power(dao), total_power);
// ...

to do this, the migration module will:

1. call back into itself via a module instantiation callback.
2. query the DAO's state and determine if it knows how to upgrade the DAO's configuration.
3. if it does not, abort.
4. dispatch the conjunction of the submessages needed to migrate each of the DAO's contracts.
5. in the submessage reply, check that the state is still correct and queryable.
6. if it is not, abort.
7. remove the itself from the DAO.

there are two configurations we must support for migration, token and membership DAOs. in both cases, our migration contract must carefully confirm by querying all of the involved contracts to check the version and name are what are expected. if any contract deviates, the transaction should be failed. contract names and versions should match those used in v1.0.0.

for the membership based DAO config, all modules must be migrated except the cw4-group module which may remain the same as it is maintained in cw-plus and its interface has not changed across versions.

for the token based DAO config, all modules must be migrated except for the cw20-base token. for this migration, if there is a manager set on the cw20-stake instance, the migration should fail unless the caller has explicitly indicated via a field in the migration module's instantiation that they would like to migrate staking contract managers.

the reason for this dance is that the manager is removed in version two, but RAW DAO uses the manager. we need to make manager removal an active action as migration could interrupt operations for DAOs that use it.

[0xekez]

i'd suggest we name this contract dao-upgrader and place it in contracts/external/. it should likely have the following interface:

pub enum ExecuteMsg {
    /// Detects the current DAO configuration and performs a migration
    /// checking state before and after to smoke test the migration's
    /// success. This module will remove itself on this message's
    /// completion regardless of the migration's success.
    MigrateV1ToV2 {
        /// Rather or not to migrate the stake_cw20 contract and its
        /// manager. If this is not set to true and a stake_cw20
        /// contract is detected in the DAO's configuration the
        /// migration will be aborted.
        migrate_stake_cw20_manager: Option<bool>,
    },
    /// Callable only by this contract.
    ///
    /// In submessage terms, say a message that results in an error
    /// "returns false" and one that succedes "returns true". Returns
    /// the logical conjunction (&&) of all the messages in operands.
    ///
    /// Under the hood this just executes them in order. We use this
    /// to respond with a single ACK when a message calls for the
    /// execution of both `CreateVouchers` and `RedeemVouchers`.
    Conjunction { operands: Vec<WasmMsg> },
}

[0xekez]

a small thing i realized last night: the module creation callbacks don't exist in v1, so we'll have to:

1. migrate the core module.
2. register the upgrader module.

which is fine. this just means that this contract should not actually concern itself with the upgrading of the core module.

[0xekez]

another note: we will want to investigate integration of token factory as part of this migration. nothing to be done now, but maybe later.

[0xekez]

another, another note that i forgot to move over from Discord discussion: we should allow add new subDAOs as part of this process.

[Art3miX]

#623