Indirection/abstraction over tokio::spawn and friends

[matheus23]

Iroh's use of tokio is very particular/opinionated.

• No use of tokio::spawn without wrapping the JoinHandle with AbortOnDropHandle
• No use of JoinSet::spawn without some loop somewhere calling tasks.join_next().await, if !tasks.is_empty() (to avoid leaking memory from task results accumulating) (EDIT: this might only be necessary if used with else inside tokio::select!, see refactor(iroh, iroh-relay): JoinSet disabling in tokio::select! #3052 )
• Every spawn must use an .instrument() for tracing.

Furthermore, for iroh in the browser (#2799) we will need to abstract away all tokio::spawn usage because it's not available in the browser! (I've already implemented a JoinSet alternative on top of wasm_bindgen_futures for exactly that reason)

Given that such an indirection would have to be created for the browser work anyways, this might be a good opportunity to introduce an API at that indirection that avoids all of the above footguns (forgetting .instrument(), leaking tasks, leaking memory).

[rklaehn]

Iroh's use of tokio is very particular/opinionated

sane is the word you are looking for...

[matheus23]

Perhaps worth keeping in mind that AbortOnDropHandle isn't the be-all end-all of task leaking: n0-computer/iroh-gossip#20

I highly doubt it but perhaps we should spend a couple of minutes thinking about if there's a good solution for this problem once we get to this issue.