Update WASI to 0.3.0, enable component-model-async

[alexcrichton]

This commit updates the vendored WASI WITs for the 0.3.0 release of WASI to this repository, updating the supported version of WASI that wasmtime-wasi runs. This additionally enables the component-model-async wasm feature by default in Wasmtime, along with -Sp3 on the CLI as well. This is intended to be a comprehensive "turn WASI 0.3.0 on by default" PR which touches a few different locations.

Apart from changing version numbers some minor changes made here are:

• Default enablement of the wasm cm-async feature is now conditional on Config::concurrency_support in addition to the compile-time feature. This means that if concurrency_support is disabled the default will be that cm-async is disabled.

• The tests/wasi.rs test suite running the upstream wasi-testsuite repository is updated to expect failures for all WASIp3 tests due to the import versions changing. This resulted in a necessary restructuring of the test to handle a few more failures in a few more locations to ensure that "should fail tests" are correctly marked as passing when they indeed do fail.

[alexcrichton]

I'll additionally clarify that my intent is to backport this to the release-46.0.0 branch upon merging to main to have Wasmtime 46.0.0 be the first with component-model-async/WASIp3 support.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Details

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  Details

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

Details

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[ricochet]

One very minor nit, otherwise lgtm including handling exit-with-code

[pchickey]

This file is missing the changes from https://github.com/WebAssembly/WASI/pull/920/changes - not sure where along the chain those got missed

[ricochet]

I see it on main: https://github.com/WebAssembly/WASI/blob/main/proposals/http/wit/worlds.wit#L35

None of the inner comments of the worlds are reflected here whether new or old.

[ricochet]

This is a wasm-tools limitation where WorldItem::Interface doesn't have a docs field so when going from wit to binary, we loose those docs. A doc comment on the service world would persist.

[alexcrichton]

Agreed yeah looks like this is a bug in wasm-tools, and thanks @ricochet for bytecodealliance/wasm-tools#2540! In the meantime the docs here don't actually get plumbed anywhere else, so this is mostly just a minor in-repo thing for us in this vendoring.

[ricochet]

Note none of the inner wit doc comments are reflected in the resolved wit (old or new).