Merge messages submessages

[ethanfrey]

Closes #953
Closes #948

This is a start now to show a new API, I will update some contracts to give a feel how easy/hard this is

• Add ReplyOn::Never.
• Add SubMsg helpers for easy transtion (BankMsg::Send{}.into() gives a SubMsg<T>)
• Remove submessages field and make messages field use SubMsg not CosmosMsg
• Tests pass in std
• Update contracts
• Tests pass in vm and other packages
• Update docstrings
• Update CHANGELOG
• Update MIGRATION

[webmaster128]

Nice start. I wonder if this is really helping if it requres us to set ID, reply on and gas limit for every message.

[ethanfrey]

I will fix a few compiler errors then leave this here for us to reflect on naming.

It seems the only real issue is the best naming/syntax to convert BankMsg or WasmMsg variants to a "fire-and-forget" type SubMsg, right?

[webmaster128]

It seems the only real issue is the best naming/syntax to convert BankMsg or WasmMsg variants to a "fire-and-forget" type SubMsg, right?

Yes, but I think it is a conceptual question: how do we preserve the simplicity of messages if we integrate them into the fully featured submessages.

[ethanfrey]

Yes, but I think it is a conceptual question: how do we preserve the simplicity of messages if we integrate them into the fully featured submessages.

That was my thinking to allow BankMsg::Send{}.into() to work like an old-style message and make this change transparent to the users.
If they want to use the power of SubMsg then they have some explicit constructors.

[ethanfrey]

Making proposed changes from #953 (comment)

One thing that I realized was Response.add_message() and Response.add_submessage(). Shall I keep them both, but do an implicit SubMsg::new on the first? So we have:

let mut res = Response::new();
res.add_message(BankMsg::Send{...});
res.add_submessage(SubMsg::reply_on_error(WasmMsg::Execute{ .. }, 1234));

They both are pretty clear APIs. add_message maintains the same usage and semantics as before. add_submessage is the same as before as well, but with some nicer SubMsg constructors.

[webmaster128]

One thing that I realized was Response.add_message() and Response.add_submessage(). Shall I keep them both, but do an implicit SubMsg::new on the first?

Good questions. Let'd do this for the first step and then see if/how we can improve from there.

[ethanfrey]

Just missing the MIGRATING.md updates, but waiting for final review and any last API changes for that.

[webmaster128]

Very cool.

Could you as part of this change also remove this?

impl Default for ReplyOn {
    fn default() -> Self {
        ReplyOn::Always
    }
}

I don't think ReplyOn should have a default anymore.

[webmaster128]

Ah, @uint could you install shellcheck on your system? It is executed automatically on all our scripts if available because of this line: command -v shellcheck >/dev/null && shellcheck "$0"

[ethanfrey]

Okay, made requested changes. Let's see if the CI catches anything

[ethanfrey]

@webmaster128 from my view, this is done and ready to merge. Can I get a final approval, or last change requests?

[webmaster128]

Nice solution 🏅 Added some minor text polishing as a commit. Good to merge.