feat(wasi): add support for wasi:[email protected]

[rvolosatovs]

Blocked on #10073

This adds support for wasi:[email protected] from https://github.com/WebAssembly/wasi-random/tree/3e99124e81d0f80872b826d161bef077ee37d241/wit-0.3.0-draft

The change is fully backwards-compatible from the guest's perspective.

The only breaking change is the wasmtime_wasi::bindings structure, where wasmtime_wasi::bindings::random is now located at wasmtime_wasi::bindings::random0_2_3.

The interface versions are almost identical apart from the @since gates.

This PR is intentionally small and well-scoped to establish the approach and enable further (mostly) backwards-compatible development and testing for WASI 0.3

For now, the existing command world is simply extended with wasi:[email protected]. In the future we'll probably want to decouple the component export and import binding generation and instead generate:

• bindings for a world, that includes both wasi:cli/[email protected] and wasi:cli/[email protected](https://github.com/WebAssembly/wasi-cli/blob/1311434b3440621a5b5fda55378587d971f0c783/wit-0.3.0-draft/imports.wit), but does not export anything
• bindings for wasi:cli/[email protected]
• bindings for wasi:cli/[email protected]

This way we will be able to accommodate 2 different versions of wasi:cli/command exported by components

[pchickey]

Thanks for getting this started!

I think that, until 0.3 is released, we should keep the existing bindings to 0.2.x at their current position in the module tree, because they have "real" users whereas 0.3 should not yet. We also don't want to bake the patch version into the module paths of the public API, since it changes regularly and upgrades are supposed to be transparent to users.

I'd support a PR that moves the canonical definition of the 0.2 bindings to bindings::p2 with a pub use at their current location that we can eventually (as 0.3 release approaches) mark as deprecated. When introducing new bindings, lets put those at bindings::p3 and behind an off-by-default cargo feature p3. The module and cargo feature should have a comment indicating these implementations are unstable and pre-standardization, and that bug/security fixes limited to p3 won't be given patch releases.

[rvolosatovs]

Thanks for getting this started!

I think that, until 0.3 is released, we should keep the existing bindings to 0.2.x at their current position in the module tree, because they have "real" users whereas 0.3 should not yet. We also don't want to bake the patch version into the module paths of the public API, since it changes regularly and upgrades are supposed to be transparent to users.

I'd support a PR that moves the canonical definition of the 0.2 bindings to bindings::p2 with a pub use at their current location that we can eventually (as 0.3 release approaches) mark as deprecated. When introducing new bindings, lets put those at bindings::p3 and behind an off-by-default cargo feature p3. The module and cargo feature should have a comment indicating these implementations are unstable and pre-standardization, and that bug/security fixes limited to p3 won't be given patch releases.

I've moved the existing WASI implementations to p2 modules with a pub use::* as suggested: #10073. Let me know what you think!

I'll meanwhile mark this PR as draft, rebase it on top of #10073 and introduce the p3 module for wasmtime-wasi