Deprecate stellar contract optimize in favor of stellar contract build --optimize.

[fnando]

What

$ stellar contract build --optimize
ℹ️ CARGO_BUILD_RUSTFLAGS=--remap-path-prefix=/Users/fnando/.cargo/registry/src= cargo rustc --manifest-path=contracts/foo/Cargo.toml --crate-type=cdylib --target=wasm32v1-none --release
    Finished `release` profile [optimized] target(s) in 0.04s
ℹ️ Build Summary:
   Wasm File: target/wasm32v1-none/release/foo.wasm (537 bytes (original size was 574 bytes))
   Wasm Hash: 9276bc278792b46e89b299bb55beffd6ca2fa2d17d723abe1ec615e6d5752485
   Wasm Size: 537 bytes optimized (original size was 574 bytes)
   Exported Functions: 2 found
     • _
     • hello
✅ Build Complete

$ stellar contract build
ℹ️ CARGO_BUILD_RUSTFLAGS=--remap-path-prefix=/Users/fnando/.cargo/registry/src= cargo rustc --manifest-path=contracts/foo/Cargo.toml --crate-type=cdylib --target=wasm32v1-none --release
    Finished `release` profile [optimized] target(s) in 0.05s
ℹ️ Build Summary:
   Wasm File: target/wasm32v1-none/release/foo.wasm (574 bytes)
   Wasm Hash: b39694f92f640414ccf28326ecf1d3b1b48981167eb00fc00739f71dac344013
   Wasm Size: 574 bytes
   Exported Functions: 2 found
     • _
     • hello
✅ Build Complete

Why

Supersedes #2045.

Known limitations

N/A

[Shaptic]

Is there any harm to this being the default behavior and dropped the need for a flag entirely? As in, why wouldn't we always just include an optimized WASM as part of the build process?

[leighmcculloch]

Looks good, but suggestion inline about the file name that gets written, I think we can omit the .optimized if we are deprecating.

[fnando]

I'm not opposed to that, especially because the additional-libs feature is enabled by default.

wdyt, @leighmcculloch?

[leighmcculloch]

Is there any harm to this being the default behavior and dropped the need for a flag entirely? As in, why wouldn't we always just include an optimized WASM as part of the build process?

I think we need to be really confident about wasm-opt and what it does to files if it is the default behaviour on. So maybe lets open an issue about that and explore that separately to this issue.

[Shaptic]

I think we need to be really confident about wasm-opt and what it does to files if it is the default behaviour on

To be clear, I think we should output both, not just the one optimized variant always.

[leighmcculloch]

I think we should output both

Why? It creates an experience that's not the same as how just using cargo build and the rust compiler works, and in general we've tried to make this as much as possible the "standard rust experience" in as many subtle ways as possible. So I think if we keep the separate file we should have a reason we're continuing to do that.

[Shaptic]

Why?

@leighmcculloch eh, just a convenience thing I guess. I would, as a developer, like the optimized version available (for visibility, if anything: I bet a decent number of devs don't even know we have an optimizer) without having to do extra steps so that I can deploy that one to mainnet when I'm ready. I get that it deviates from Rustisms, but it is better devx imo.

Edit: I didn't realize that we may not want to recommend the optimized one by default, though, which changes the equation a bit from our perspective by making it explicitly opt-in.