Document concurrent instance reuse in wasi:http/service

[alexcrichton]

This commit adds a documentation block to the wasi:http/service world that's the result of discussions in today's WASI subgroup meeting, #918, and #919. The documentation here indicates a few properties around concurrent instance reuse, namely:

• Guests should expect to be concurrently reused. If this is not acceptable then guests should disable reuse through backpressure mechanisms.

• Guests should ensure that outgoing HTTP requests are done within the context of the original root task, or the original invocation of handler. If guests can't implement this then they're expected to use backpressure mechanisms instead.

The overall conclusion of the various discussions that have happened over the past week or so is that it's not possible to provide the attribute behavior some hosts require exclusively through either in-guest interactions or pure-host interactions. Instead being able to reliably provide accurate attribution requires specifically outlining guidelines for both guests and hosts. The mechanism intended to be used for attribution is then:

• For hosts such as Wasmtime calls to imports will be able to reflect on the current async call stack, notably the root export task. Hosts can then use this to correlate an identifier provided when a root task is created, providing a strong link from the import call to whatever export initiated it. This is expected to work as-is for some guest languages, such as Rust, but this is also not a bulletproof solution. Guests can always internally call imports from any currently-running task, and additionally languages such as JS and Go at this time are structured in such a way where imports are not always naturally called from the originating export task.

• To enable languages like JS and Go to be able to leverage concurrent reuse while providing accurate attribution of outgoing requests to incoming requests, the plan is to eventually add and specify intrinsics on the component model level to, in a scoped fashion, mutate the async call stack. For example a guest would be able to say "I'm about to do some work for this component model task". When Wasmtime reflects on the async call graph at that time it'd see this and understand that the attribution needs to be slightly adjusted to what it would otherwise by default be.

The goal with these addition is to enable hosts to be able to reliably expect to attribute outgoing requests to incoming requests (via async call graph inspection), provide guests the ability to work today (either naturally or disabling concurrent reuse via backpressure), and ensure that well-behaved and idiomatic guests can work reliably with concurrent reuse in the long-run (via component model intrinsics to massage the async backtrace that hosts operate with). When this is all combined it's expected to resolve the concerns of #918 and #919 with idiomatic bindings in guests and hosts alike.

Closes #918
Closes #919

[lukewagner]

Looks good from my perspective

[badeend]

Agree with these changes.

I also think that using the CM async callstack to correlate exports with imports is the best (or: least bad) solution put forward so far to solve #918 & #919.