This PR (internal to my clone, not upstream) is a proof of concept that join_me_maybe::join can replace select! loops in nontrivial cases. There are some scattered changes that go against the grain of surrounding code, and it would need a fair bit of cleanup if it was going to be seriously reviewed, but the goal here is just showing (myself) that it's possible to get it compiling and passing tests. This required adding several features to join_me_maybe along the way, and it was a useful forcing function.

My motivation was this post by @nikomatsakis: https://smallcultfollowing.com/babysteps/blog/2022/06/13/async-cancellation-a-case-study-of-pub-sub-in-mini-redis. The thesis is that select! is error-prone, and it would be nice to replace it in common use cases, but it also has some superpowers that make it hard to replace. select! arms get lowered to a match in the calling function, which means they can mutate the same variables, and they can also short-circuit with return or ?. Since an arm body doesn't run until select! has dropped all the "scrutinee" futures, borrows in the bodies don't conflict with those futures either. At the same time, for better or worse, it's also possible to .await async function calls in the bodies. join_me_maybe approaches this with several similar features:

• Arm bodies get lowered to a match, as in select!. That means that only one body can run at a time. However, to avoid deadlocks, the bodies (whichever one is running at any given time) are still concurrent with all the "scrutinee" futures. (It's a join! rather than a select!, so by default we wait for all of them.)
• Stream support. We can execute a body expression for each element that comes out of a stream.
• Return support. Error handling with ? works. This requires some aggressive macro shenanigans, because each body can also evaluate to a value "the normal way" (though we don't use that in this case).
• Interior mutability of "labeled" streams (and technically futures too). See this section of the join_me_maybe docs. This is the most complicated bit, and the most likely to change in future versions of join_me_maybe. For each labeled future or stream, there's a "canceller" in scope, and it supports a with_mut method that exposes the labeled future/stream for mutation. That's what lets us add work to the StreamMap over time. Though see the TODO above that join arm.