Add dispatcher to test contracts calling contracts

[ethanfrey]

Minimal emulation of some of the sdk code, especially for the (non-wasm) unit tests.

Allow to register multiple modules with unique HumanAddr.
Launch a message on a Dispatcher and if it returns a message, attempt to route to other modules and so on.

Dispatcher exposes handle and query. query allows raw queries and smart queries to all the registered modules. Note that Dispatcher must handle multiple MockStorage for the contracts as well.

This is only designed for test code and should be optimized for ergonomics not performance.

[ethanfrey]

@webmaster128 do you have any opinions here? The main use case in my mind is erc20 atomic swap contract testing (you need to have 2 contracts interact). Design ideas would be great. I just know this should work easily (whatever that means)

[ethanfrey]

Short ideal is dispatcher takes api and storage as constructor.

Define a module as 3 function pointers, to init handle and query.

The dispatcher has the following methods

init(Module, Params, InitMsg) -> Result

handle(HumanAddr, Params, HandleMsg) -> Result<data? Log?>

query(HumanAddr, QueryMsg) -> Result

The human address is auto generated on init and a unique storage is set up for it.

[ethanfrey]

I think to do this as a separate repo, like cw-storage to keep cosmwasm clean (and allow a faster iteration cycle to start). Unless a good reason to embed it in cosmwasm (next to cosmwasm-vm)

Also, it would need to pull in some sample contracts (like dummy bank implementation) and cw-storage and I would not like to throw all of that into the cosmwasm repo. (Or yes, we throw everything there, but not some in, some out).

[webmaster128]

@webmaster128 do you have any opinions here?

Right now it is entirely unclear to me how composition is supposed to work. For this reason I'm lost with the rest of this ticket. E.g. I don't understand why this is about tests when we don't have a bunch of happy path runtime compositions to look at. Maybe let's build up a strategy for composition first and document it.

[ethanfrey]

I will add a doc before the code. But the idea is expressed by returning messages now (adding queries later). I think this is more or less documented, mainly it needs concrete examples. And I think tests are the best documentation of how things work code-level, which is why I focus on that here.

[ethanfrey]

Not going to build a dispatcher as part of this repo. Maybe in another repo. Closing it