`split` sender's cancellation behavior is unexpected

[ericniebler]

Cancelling any of the split senders causes the underlying operation to be cancelled. It should probably only be cancelled if all the split senders are cancelled.

[lewissbaker]

The reason why the split() semantics are the way it is to prevent the case where:

• two consumers, A and B have copies of the split sender
• consumer A connects, starts and then cancels their sender, detaching from the operation
• the operation is still running in the background because consumer B still has its sender and might be about to connect/start to attach to the operation
• something happens and B destroys its sender without connect/start

This is exactly the same scenario as ensure_started() and has the same lifetime footguns.

If we want split to have the behaviour of only cancelling when the last consumer cancels then it needs to be tied to some form of scope. This could either be an async-scope, with a spawn_shared() function. Or it could be a structured algorithm such as let_concurrent_shared(s, [](auto copyable_s) { ... }).

[lewissbaker]

I have created #263 to track creating a better split() algorithm.

[lewissbaker]

Closing as duplicate to consolidate work into #263.