Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT wor

Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT world that hosts
debug components that have access to "host debug powers" via a
debugging API, and the ability to load such a debug-component and give
it control of the main program as a debuggee when using `wasmtime
run`.

The WIT is namespaced to `bytecodealliance:wasmtime` and is slightly
aspirational in places: for example, the host does not yet implement
injection of early return values or exception-throws. I intend to fill
out a series of TODO issues once this all lands to track followup
("post-MVP") work.

This PR does not include any debug components. I separately have a
gdbstub component, with which I tested and co-developed this host-side
implementation. My plan is to land it in a followup PR as a component
that will be embedded in/shipped with the Wasmtime CLI and available
under an easy-to-use CLI option. Once we have that gdbstub component,
we can also implement end-to-end integration tests that boot up LLDB
and run through an expected interaction. (Separately, those
integration tests will require a release of wasi-sdk to ship an LLDB
binary that we can use.) As such, there are no real tests in this PR:
interesting behaviors only really occur with a full end-to-end flow.

The integration with the CLI is a little awkward (we internally build
another `wasmtime run` command that invokes the debug component, and
tie it together with the debuggee via a special `invoke_debugger` API;
this seemed less bad than reworking all of the WASI setup to be more
reusable). Happy to take more ideas here.

* Review feedback.

* Review feedback.

* Review feedback: update vendor-wit.sh.

* Review feedback: -Ddebugger-arg= -> -Darg=.

* Review feedback.

* Review feedback.

* Review feedback: factor host.rs into several submodules.

* Review feedback: rename Debugger to Debuggee on host side.

* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.

* Review feedback.

* Review feedback.

* Add simple debug-component tests.

* Add wasm32-wasip2 target in a few places in CI

* Cargo vets for wstd dependency.

* Add wasm32-wasip2 in more places

* fix debug-component test dependence on componentization byte offsets

* Review feedback.

* Fix cancel-safety of EventFuture.

* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.

* Review feedback.

* Review feedback: strip down WASI imports in debugger world.

* fold debugger test component back into wasip1 + adapter test artifact compilation flow

show more ...

Migrate debugger to `wasmtime::error` (#12261)

Debugger: add top-level crate and async wrapper allowing for a "debugger environment". (#12183)

* Debugger: add top-level crate and async wrapper allowing for a "debug environment".

The debug suppo

Debugger: add top-level crate and async wrapper allowing for a "debugger environment". (#12183)

* Debugger: add top-level crate and async wrapper allowing for a "debug environment".

The debug support in Wasmtime so far is structured around async
callbacks that occur at certain kinds of events, like breakpoints. This
is a suitable foundation but makes for an awkward implementation of a
top-level debugger implementation, which likely has an event loop
dealing with user commands (via a UI or a protocol connection) and
expects to perform actions such as "run until next breakpoint".

This PR introduces a new crate that wraps a `Store` in a `Debugger`.
This wrapper embodies an inner async body that can perform whatever
actions it likes on the `Store` that is passed back in. This inner body
is spawned as an async task. The debugger wrapper registers its own
`DebugHandler` callback that communicates with the outside world via
bidirectional command/response queues.

On the "outside", the `Debugger` presents an interface suitable for
inserting into a debug protocol server or UI: an async method that runs
until next event and returns that event, and a method that permits
querying or modifying the store whenever the `run` method is not
executing. The latter operates by sending a closure over the queue,
because the `Store` must continue to be owned by the async task that is
(still) running and suspended in async callbacks.

Right now, this is exercised only via a few unit tests, but the intent
is to next build up the "top half" of the debugger using this
abstraction, e.g. by running a gdbstub protocol server (likely as a Wasm
component in a "debug-main WIT world" -- RFC needed for this).

Also, when we eventually move debugging over to native use of
`run_concurrent`, this paradigm should remain mostly unchanged at this
level of API: there can still be an object that has an async method that
runs and yields the next event, and there can still be a method that
takes a closure that can operate (within its scope only) on the `Store`.

A few warts that I could use feedback on:

- Cancelation safety is weird. Fibers panic when dropped before
execution of their body completes, and this seems to mean that we
can't allow a `Debugger` to drop early (or at least, the `tokio::test`
unit test that owns the runtime that runs the async task to finish
before the debugged body completes!). If there is a better way to
handle cancelation safety here, I'm all ears.

- It's not clear to me if the boxed-closure-and-`Any` approach to
providing access to the `Store` is the best we can do, but I suspect
it is.

* Cancel safety!

* Add new crate to publish.rs script.

* Review feedback.

* Review feedback: state diagram.

* Update after merge from main: new DebugEvent for epoch yields.

* Make Debugger drop-safe by making debug event callbacks compatible with fiber teardown.

* CI fix on `debugger` crate manifest.

- Do not link to non-existent README in new crate.
- Remove a few other attributes that our internal crates don't have (now
the set of attributes at the top level is the same as for the new
error crate).

show more ...