Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)

* Migrate wiggle and wiggle generate to `wasmtime::error`

* Fix testing `wiggle` and `wiggle-test` in isolation

When doing plain old `cargo te

Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)

* Migrate wiggle and wiggle generate to `wasmtime::error`

* Fix testing `wiggle` and `wiggle-test` in isolation

When doing plain old `cargo test -p wiggle` (or `wiggle-test`) the test would
fail due to linking errors because Wasmtime's `std` cargo feature (and maybe
others) wasn't being enabled. The crate's tests would pass when run as part of
the whole workspace, however, because of cargo feature resolution and other
crates that enabled the necessary features, which is why CI is green.

* Remove direct anyhow dependency in wiggle-test

* Migrate wasi-nn to `wasmtime::error`

* Migrate wasi-keyvalue to `wasmtime::error`

* Migrate wasi-io to `wasmtime::error`

* Migrate wasi-http to `wasmtime::error`

* Migrate wasi-config to `wasmtime::error`

* Migrate wasi-common to `wastime::error`

This is another interesting one because wasi-common is used internally to
Wasmtime but also by other projects. Therefore, rather than using
`wastime::error::*` and making `wasmtime` a hard dependency, we use just
`wasmtime_environ::error`.

* cargo fmt

* Migrate wasmtime-wasi to `wasmtime::error`

show more ...

wasip3: Update std{out,err} implementation (#11618)

* wasip3: Update std{out,err} implementation

Match the WASIp2 stdio implementation and "lie" about stdio actually
being async. Instead of using T

wasip3: Update std{out,err} implementation (#11618)

* wasip3: Update std{out,err} implementation

Match the WASIp2 stdio implementation and "lie" about stdio actually
being async. Instead of using Tokio's primitives use the `std::io`
primitives which will block the current program while the output is
produced. This matches WASIp2 semantics and we always have the option of
making this more async in the future (or even have it as a runtime
flag). This avoids the need to call `poll_flush` in stdio
unconditionally in the `wasi:cli` implementation which didn't feel quite
right.

* One fewer run for Windows

It's got a shorter command line length limit

show more ...

Share stdio implementations in WASIp{2,3} (#11368)

* Share stdio implementations in WASIp{2,3}

This commit is a refactoring of the
`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more co

Share stdio implementations in WASIp{2,3} (#11368)

* Share stdio implementations in WASIp{2,3}

This commit is a refactoring of the
`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more code. The
generic trait object that represents stdio now has the ability to
acquire either a p2 stream or an async-based stream. The acquisition of
p2 has a default implementation so in the future this can be primarily
`Async{Read,Write}`-based.

Many trait implementations and types and such were all consolidated
together into the `wasmtime_wasi::cli` module. One-off implementations
in p2/p3 are now shared in one location and `WasiCtxBuilder` no longer
needs any generics for different stdio streams.

Functionally this necessitated the addition of `Async{Read,Write}`
implementations for some "base" implementations of stdio primitives.
Implementations were mostly trivial except for a few adapters which were
significantly more complicated, namely the `Async{Read,Write}Stream`
adapter which converts a single `Async{Read,Write}` into the stdio of a
component.

Finally the stdin implementation for p3 was refactored to avoid use of
`tokio::io::stdin()` which generally isn't safe to use. It's replaced
with a custom `AsyncRead` using the worker thread implementation we have
in the crate already.

Eventually I hope to remove the distinction between `p{2,3}::WasiCtx`
and have these be the same type. This will make it nicer to only have a
single `WasiView` trait and additionally make it easier to
simultaneously implement all of WASIp{1,2,3}.

* Fix build of C API

* Fix build of `wasmtime serve`

show more ...