chore: update wasmd to v0.26.0

[p0mvn]

Closes: #1502

What is the purpose of the change

Upgrading cosmwasm to v0.26.0. Chose v0.26.0 because v0.27 is rc still.

Brief Changelog

• created a tag v0.26.0-osmo and branch: https://github.com/osmosis-labs/wasmd/tree/v0.26.0-osmo
• updated wasmd to v0.26.0-osmo
• updated wasmvm to 1.0.0-beta10 according to https://github.com/osmosis-labs/wasmd#compatibility
• updated Docker images according to https://github.com/CosmWasm/wasmd/blob/dc5ef6fe84f0a5e3b0894692a18cc48fb5b00adf/Dockerfile#L22

Testing and Verifying

This change is a trivial rework / code cleanup without any test coverage.

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes? no
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? (yes / no)
• How is the feature or change documented? not applicable

[codecov-commenter]

Codecov Report

Merging #1516 (2800dcd) into main (f149135) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1516   +/-   ##
=======================================
  Coverage   19.50%   19.50%           
=======================================
  Files         231      231           
  Lines       31527    31527           
=======================================
  Hits         6150     6150           
  Misses      24251    24251           
  Partials     1126     1126           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9463346...2800dcd. Read the comment docs.

[faddat]

It's common practice in cosmos to consume the built binaries of wasmvm, but I'd like to note that the way that we build this stuff scares me because I have seen it cause problems in prod on Juno.

I don't like the usage of env/arg in the dockerfiles, and my suggestion to resolve this issue is that we build from source, from a specific commit for wasmvm.

With the approach here, we are putting binary blobs into osmosis.

Please don't consider this review to be a blocker/showstopper. This is more me getting this thought out of knocking around my mind and causing the creation of new docker images and the like and into a public forum where we can discuss it.

[ValarDragon]

@faddat want to get that transcribed into an issue?

[ValarDragon]

@p0mvn can we use the latest v0.27.0 rc ? I synced with @ethanfrey earlier today, v0.27.0 unless something unexpected happens, is getting released before our target for the final v9 release, so this should be fine.

[p0mvn]

@p0mvn can we use the latest v0.27.0 rc ? I synced with @ethanfrey earlier today, v0.27.0 unless something unexpected happens, is getting released before our target for the final v9 release, so this should be fine.

Yes, I'm trying to adapt v0.27 wasmd right now but, as @faddat pointed out in #1502, it requires backporting some PRs from Cosmos SDK upstream. I'm currently reconciling the issues with these PRs on our fork

[p0mvn]

This is what needs to be backported: cosmos/cosmos-sdk#11267

[ethanfrey]

it would be great to get wasmd 0.27 in. rc3 is api complete. and yes, you need latest Cosmos.sdk for state sync support (big relief for validators)

if we can help, let me know, but I think it is mainly osmosis forks for cosmos libs

[p0mvn]

it would be great to get wasmd 0.27 in. rc3 is api complete. and yes, you need latest Cosmos.sdk for state sync support (big relief for validators)

if we can help, let me know, but I think it is mainly osmosis forks for cosmos libs

Thanks @ethanfrey . Already updated all Osmosis forks for v0.27, just need to update Osmosis now. Closing this PR in favor of v0.27.0.rc3