Rework cosmwasm-core

[aumetra]

This PR removes cosmwasm-core again, as internally discussed.
The introduction of this crate added unnecessary maintainance burdens for questionable benefits.

Closes #2145

[aumetra]

Sorry, but I have no idea how that test ever even passed. The tests always ran on a non-wasm32 target, and they always ran with the std feature enabled.

This feels like something that should have never worked? Or am I misreading the previous code?

[webmaster128]

Seems like something in the CI job sets RUST_BACKTRACE implicitly. I can reproduce the passing/failing test locally with

(cd packages/std && RUST_BACKTRACE=0 cargo test implements_debug)
(cd packages/std && RUST_BACKTRACE=1 cargo test implements_debug)

We should probably unset RUST_BACKTRACE in the CI job before running our script as the test code expects it to be unset

[aumetra]

Oh, I didn't see that this is a new GitHub Actions workflow

[aumetra]

Should we gate the Ed25519, p256, k256, etc. things of the crypto crate also behind the target triple? Shouldn't be too hard tbh.

[webmaster128]

Should we gate the Ed25519, p256, k256, etc. things of the crypto crate also behind the target triple? Shouldn't be too hard tbh.

Why would we do that? All of cosmwasm-crypto is not pulled in for Wasm builds: https://github.com/CosmWasm/cosmwasm/blob/v2.0.3/packages/std/Cargo.toml#L67-L69

[aumetra]

Why would we do that? All of cosmwasm-crypto is not pulled in for Wasm builds

Not in the current version, but it is pulled in to provide the re-exports of the BLS generators. Either we move them from the crypto package into std, or we gate the other features (or we hope LTO fixes the size via dead code elimination)

[webmaster128]

Either we move them from the crypto package into std, or we gate the other features (or we hope LTO fixes the size via dead code elimination)

I looked a bit into that today. I think having cosmwasm-crypto as a dependency for the contract builds is a problem because of compile time and debugability for getrandom problems (folks always suspect cosmwasm-crypto to be the source of their compilation problems). The crate should only be needed for host code (VM and testing), not contract code.

So I propose solution 3: we use this opportunity to start cosmwasm-core with just BLS12_381_G1_GENERATOR, BLS12_381_G2_GENERATOR. This can then be a shared dependency for std and crypto.

The concept of a lightweight no_std compatible cosmwasm-core is good as long as

1. It does not depend on cosmwasm-crypto
2. Re-exports are not renamed

With #2136 we can get more types in there as long as StdError remains in cosmwasm-std.

[aumetra]

Really funny, apparently non_local_definitions is a nightly lint.
I guess I'll have to live with two warnings across the workspace for now.

[webmaster128]

Nice stuff