Add 'Component Instance Lifetime' section to Concurrency.md

[lukewagner]

This PR adds a new section proposing default expectations around component instance lifetimes in the presence of async based on some recent discussions with @alexcrichton, @dicej and @tschneidereit about what the default instance reuse/lifetime policies should be in Wasmtime for WASI HTTP. Ultimately, the host can create or destroy component instances whenever it wants, so this isn't really normative, but it still seems useful to document default expectations is to align producer toolchains and runtimes and potentially suss out other interesting use cases.

[alexcrichton]

lgtm 👍

FWIW the companion Wasmtime PR is bytecodealliance/wasmtime#13246

[badeend]

This maps pretty much exactly how I'd expect it to behave. 👍

---

The current wording is tied specifically to threads, tasks, streams & futures. Maybe this could be generalized into a single conceptual keep-alive counter at the component instance level?

• Start of export func task: +1
• Task returned: -1
• Resource handed out: +1
• Resource dropped: -1
• etc.

and for additional manual control: keep-alive.inc & keep-alive.dec (similar to backpressure.inc & backpressure.dec)

[lukewagner]

@badeend Ah, cool idea! Thinking about whether I could take this all the way into the Python CABI code, the tricky bit is that we only care about stream/future ends when the host is holding the other end; if we inc/dec for component-to-component end pairs, I think that'll end up keeping component instances alive longer than expected. At the moment, things are intentionally set up to be rather agnostic to each end of the stream of whether the other end of the stream is guest/host. Not that this couldn't be fixed, but it would be a more invasive fix than adding a few well-placed increments and decrements. I expect when we get to runtime instantiation (#423) these rules will end up getting reified in the semantics of resource.droping a component instance, so that would be an opportunity to formalize this a bit more.

Also, good point about keep-alive.{inc,dec} (vs. set, to avoid the clobbering problems); I was wondering about that too.

[lukewagner]

@badeend ... and it's also a good point that the built-ins might not be thread-specific, they might be instance-specific. I tweaked the wording to not presume the exact solution and just state the goal.