This PR adds the option to use custom address generator with WasmKeeper (which by default uses the existing address generator).

Rationale behind it being that some contracts, like ours, might perform address validations. In our case we need to use bech32-compatible addresses and the ones currently being generated (contract{n}) aren't such.

This PR extends the efforts of #9, which added the foundations for adding custom IBC keeper and thus support IBC messages.

This PR also makes it possible to compile cw-multi-test without the need of adding stargate as a required feature to cosmwasm-std, by defining mock versions of both the IBC and Governance keeper modules.

Support for modules handling stargate messages - IBC and Gov. No implementation of particular modules - by default just FailingModule, but possible to overwrite with custom, so it is possible tot test contracts sending IBC messages.

Follow up of #9

• Added couple more bounds in multi-tests where defaults were taken in place of IBC/Gov
• Added dispatching of Gov messages
• Tests for both IBC and Gov messages

Motivation: This would allow downstream crates to utilize the recently added IBC capabilities of the crate. As of now, there is no way to provide functioning handler for IBC messages.

Pretty much self explanatory, I need to be able to query for the supply of a native token during testing.

I don't know how to get around the non_exhaustive issue, that's why I've redefined the SupplyResponse struct.

People are facing the problem that if they have a contract emitting IBC messages, it is technically impossible to test them - passing any IBC message through a router will always cause panic. It is semi-solved for staking/custom messages by a separate module for them to fail by default, but possible to overwrite their behaviour. For now, the problem exists for IBC, Stargate and Gov messages (so basically anything introduced via a stargate feature).

Another problem is how staking is implemented - it just enables the stargate feature flag by default (enabling relevant features in cosmwasm-std, but what would happen if someone would explicitly disable it - via no-default-fetures? It would fail to compile because of a lack of staking-related types in cw-std).

This approach of the fixed module set has proven to be difficult to maintain properly. I have another idea. Let's model a module like something accepting any cosmos message and handling it optionally - if it knows how to handle it, it will return a proper result. If not - it would return some None equivalent. If any module manages to handle the message, its processing is finished successfully.

To make it easy, I would create two generic "modules" or better "handlers". DefaultHandler would take any message and report an "unhandled message" error. One called on the very end of a chain. The other one would be FallbackHandler<Module, Fallback>. The FallbackHandler tries to handle a message using Module, and if it fails, it delegates handling it to Fallback. Fallback is typically another FallbackHandler or DefaultHandler at the end - basically a simple linked list.

Now to make it even better API-wise, FallbackHandler would take an even better form: FallbackHandler<T, Filter<T>, Module<T>, Fallback>, where Filter takes a Cosmos message, returning some Option<T>, and Module<T> is a handler taking a T (eg. BankMsg) handling it. If the filter returns Some, then only my Module is allowed to handle the message. Otherwise, it is forwarded further (so it is shortcut-break if there is an unsupported bank message in future).

This also allows changing the handler for a particular message - as they are unique identified with T - it would allow keeping the same Api we have now with some defaults (bank, wasmkeeper), which can be substituted with custom messages. It would also allow easily feature-enable some other implementations in future or allow others to provide custom implementation of modules not yet implemented in MT at all, under some feature flags.

Any thoughts? I am happy to provide PoC of that.

The current implementation makes two restrictive decisions:

1. The only way to create a wrapper is to pass function pointers (can't pass closures or any ol impl Fn)
2. All the fields are private

The internal new() creator is able to create a closure from the passed-in function pointer, but the current setup disallows the caller to do this too. e.g. it may want to wrap functions before passing them in.

Suggestion: change the new() functions to accept any impl Fn

edit: the Contract trait is pub so making the fields on ContractWrapper wouldn't add much. The real blocker is using the simple new() methods with closures being passed in

Multitests relying on TgradeApp must now (since cw-plus 0.12.1) use TgradeQuery. Because TgradeQuery is defined at the app level.

This imposes some restrictions to our test code, in that we cannot in principle call contracts that don't implement the custom TgradeQuery.

There are some workarounds already, like the TgradeWrapper::new_with_empty constructor, and the associated with_sudo/reply/migrate_empty builder-like helpers.

It would simplify and generalise testing considerably if the message / query type could be specified at least at the contract level (i.e. in or as part of the store_code call). That would still require that all the entry points for that contract are of the same type. But, it will allow for easy heterogeneous "contracts with custom message" multi tests. And will be better suited for the future, in which we can have contracts with more than one custom message type (besides Empty).

Doing this could be daunting, though, as this custom type is currently associated to everything from app and deps to responses.

Related issues / comments:

• https://github.com/CosmWasm/cw-plus/pull/660#issuecomment-1043177477
• https://github.com/confio/tfi/pull/68
• https://github.com/confio/poe-contracts/pull/103#issue-1137254582
• https://github.com/confio/poe-contracts/pull/109

We now have support for Custom Msg and Queries, and an easy way to plug in Staking and Distribution support. (#266)

One missing feature is being able to simulate IBC calls between 2 apps. This will require significant changes to the App structure and some coordinator that controls 2 apps. Rather than hide this as a checkbox, it makes sense to pull it into a full-blown issue to discuss.