feat: QOL GetDefaultFeatures

[Reecepbcups]

Feature

It would be nice to have wasmvm.GetDefaultFeatures() to return the default features. This is also used in the internal test.

Reason

When upgrading, its common to forget this ( We did for juno v14). It would be nice for this to be upstream to ensure its handled when chains upgrade their wasmvm automatically for future 1.3+ wasmvm new features

Before & After

app.go

[webmaster128]

There is no such thing as default capabilities in wasmvm. The chain using wasmvm need to support this the features. If I added fobar here but the chain does not support it, an wasmvm upgrade would break things.

If we add it, it should be done in wasmd. Wasmd already maintains such a list.

[webmaster128]

We need to rename this variable to capabilities (see https://github.com/CosmWasm/cosmwasm/blob/main/docs/CAPABILITIES.md for more on that)

[webmaster128]

#414

[webmaster128]

Hmm, it's here but only as an example, not a default value: https://github.com/CosmWasm/wasmd/blob/v0.31.0/app/app.go#L517. There should be a default which you can expand.

[Reecepbcups]

There is no such thing as default capabilities in wasmvm. The chain using wasmvm need to support this the features. If I added fobar here but the chain does not support it, an wasmvm upgrade would break things.

If we add it, it should be done in wasmd. Wasmd already maintains such a list.

my idea here is that each wasmvm version as upgraded, would then add the cosmwasm_1_# to this. Then wasmd would call this like you mentioned with https://github.com/CosmWasm/wasmd/blob/v0.31.0/app/app.go#L517

(Since cosmwasm_1_2 is in reference to wasmvm, I really feel it makes sense to add here?)

Then in wasmd you would do

availableCapabilities := "iterator,staking,stargate," + wasmvm.GetDefaultCapabilities(). Then as versions increase for wasmvm, they auto persist to wasmd & the upstream chain?

yay / nay?

[webmaster128]

nay, capabilities are always negotiated between chain and contract