consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or

consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or task in all cases when entering
a component instance, even when component model async features were enabled. In
particular, entering an instance via a sync-to-sync, guest-to-guest adapter, via
`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating a
thread or task, creating panics and/or instance mismatches in certain cases.

This commit addresses all those cases and also adds assertions to all CM async
intrinsics to verify that the caller instance matches the most-recently-pushed
task. Note that we still skip pushing and popping threads and tasks if no CM
async features are enabled in the `Config`.

In order to populate the `GuestTask::instance` field for tasks created as part
of `Linker::instantiate[_async]` calls, I had to add a
`RuntimeComponentInstanceIndex` field to `GlobalInitializer::InstantiateModule`
and friends so it would be available when needed.

While testing this, I uncovered and fixed a couple of related issues:

- We weren't checking the `may_leave` flag when guest-to-guest calling a resource destructor
- We weren't checking whether a subtask was ready to delete (e.g. that no threads were still running) before attempting to delete it while deleting its supertask

* fix warnings when component-model-async feature disabled

* address review feedback

* push a task when calling a resource dtor host-to-guest

* add tests which call `thread.index` from realloc and post-return functions

...and assert that the indexes match as expected.

Getting the post-return test to pass required moving the call to
`StoreOpaque::exit_sync_call` to after the post-return function is called.

show more ...

make async tests using `ready` interface more robust (#12360)

This changes the `ready` interface used by `component-async-tests` from:

```
interface ready {
// Set the `ready` state
set-ready:

make async tests using `ready` interface more robust (#12360)

This changes the `ready` interface used by `component-async-tests` from:

```
interface ready {
// Set the `ready` state
set-ready: func(ready: bool);
// Block until `ready` is `true`
when-ready: async func();
}
```
to:
```
interface ready {
resource thing {
constructor();
set-ready: func(ready: bool);
when-ready: async func();
}
}
```

The problem with the original version was that it required global state and thus
caused cross-talk across concurrent tasks. Due to implementation details inside
Wasmtime, the tests worked anyway, but
https://github.com/bytecodealliance/wasmtime/pull/12357 perturbed that and
revealed how fragile tests based on that interface were.

The new version puts the state inside a resource type, allowing each task create
its own instance of that resource type and thereby avoid crosstalk.

show more ...

Update wasm-tools dependencies (#12031)

* Change separator style

* Update wasm-tools dependencies

* Also update wit-bindgen
* Drop `[async]` name prefixes
* Plumb `async` as part of a function ty

Update wasm-tools dependencies (#12031)

* Change separator style

* Update wasm-tools dependencies

* Also update wit-bindgen
* Drop `[async]` name prefixes
* Plumb `async` as part of a function type

Runtime handling of async functions and new traps are to be implemented
in subsequent commits. This is just getting everything running again.

* Run clang-format, also add test

* Fix some more wast tests

---------

Co-authored-by: Sy Brand <[email protected]>

show more ...

Return `true` from `yield` intrinsic if `EVENT_CANCELLED` is pending (#11542)

Fixes #11191

Signed-off-by: Joel Dice <[email protected]>