Expose SDK 0.44 functionality under feature flag

[ethanfrey]

There are some new items we can support in a post-stargaze flags. Stuff that is present in the 0.43/0.44/0.45 sdk series. We can enable them indpendently under feature flags in a backwards compatible way:

Not done:

• Should we add support for "feegrant" to cosmwasm?
  • I think we should allow contracts to issue fee grants and revoke them (so a multisig can cover fees paid by members)
• Should we add support for "authz" to cosmwasm?
  • I don't see the need for contracts to use it. Users can use it on basic accounts, contracts have other ways to do this (eg cw1)

Done in #1302:

• Should we integrate IBC version negotiation, Support IBC version negotiation in contracts wasmvm#269?
  • This is first implemented in ibcv2 then improved after my feedback in ibcv3. I will wait til ibcv3 is tagged then support this one, by providing a backwards compatible enhancement to the ibc query types. If the contract doesn't use that, it defaults to current functionality - accept the version provided or error - no way to suggest a different one
• Should we pass the IBC relayer address to the contract?
  • This requires ibcv2 and would be great to expose with a flag, not an option. If you require ibcv2 then it will always be present

These are my thoughts on them. Once we decide which features we want to cover, we can break out issues to define the API and implement.

[alpe]

• Should we support WeightedVoteOptions in gov voting?

[the-frey]

@alpe been having a discussion about this with a team building on Juno that were asking about WeightedVoteOption - I assume there's some complexity that I'm not seeing that means it's not as simple as updating the cosmos message types and adding some tests?

[ethanfrey]

The point is backwards compatibility with other chains not using the newer vote format.

CosmWasm contracts should work on any reasonable runtime (at least from Cosmos sdk 0.45) and we cannot break that with newer cosmwasm versions

[the-frey]

Right, okay that makes sense. What does that mean in future in terms of SDK functionality that is not backwards-compatible?

[webmaster128]

Since we do not have gov queries yet, are we talking about adding support for MsgVoteWeighted (new in SDK 0.43) in addition to MsgVote (still supported)? As those are different messages in Cosmos SDK anyways, I don't see an issue adding support for the new message type other than the feature gating discussed in #1367.

[webmaster128]

MsgVoteWeighted support is now tracked in #1435.

[chipshort]

Feegrant coming from a contract is tracked in #2238 now. The future of authz is too uncertain to implement it at the moment.