allow instance to be reentered while yielding

[dicej]

The spec says we should allow this, so now we do.

Thansk to Alex for the test case!

Fixes #12128

[alexcrichton]

Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically may_enter was a thing but it's no longer present in CanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handle may_enter to align with the spec)

[dicej]

Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically may_enter was a thing but it's no longer present in CanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handle may_enter to align with the spec)

Search for trap_if_on_the_stack in CanonicalABI.md and the prose that follows. I agree that some renaming and/or refactoring may be due.

[dicej]

I'm investigating the test failure; looks like dropping a subtask while it's yielding in an infinite loop will require some extra care. EDIT: the problem is more fundamental than that, and the refactoring Alex suggested above is going to be necessary in order to fix #12128 properly.

[alexcrichton]

Joel and I discussed this and the conclusion is that the may_enter handling in Wasmtime is outdated and no longer in sync with the spec after component-model-async refactors. Effectively we need to rebuild the reentrance check from scratch throughout Wasmtime and avoid using may_enter for the triple-purpose of: preventing reentrance, requiring post_return, and lockdown-on-trap. This'll require refactors internally to use a new component-model-async helper but will have an impact on component adapter performance as well. This all corresponds to trap_if_on_the_stack in the spec (scroll down a bit)