Add Receiver::new_sender to channels

[oowekyala]

This change gives some channel::Receivers the ability to spawn new senders at will.

Currently, Receivers are disconnected as soon as the Sender count reaches zero, as new Senders can only be created by cloning an existing one. Disconnected receivers do not block on recv and such, instead they just fail immediately.

This didn't quite fit my use case, where I need to have the ability to create new Senders when I want to, and also get the non-blocking behavior if there is no Sender alive. With the current API, I have to keep a prototype Sender which is always alive and which I can clone whenever I want. The problem is that since the prototype is always alive, the channel never gets disconnected. That means calls to recv stay blocking, even when we know that no message will ever be sent through the Sender prototype, because its only purpose is to produce new Senders.

This change creates a new Receiver type that supports creating new Sender instances. That means, I don't need to keep a Sender prototype anymore, so my Receiver is non-blocking when I know there is no real Sender alive. But even after the channel was disconnected, you can "reconnect" it by spawning new senders.

Obviously this method cannot appear in the API of channel flavours like tick or never, since the point of those is to expose only a receiver. This means, we need two different types for Receiver. I put that new API in a separate submodule so that it's easy to import and document. That submodule only supports creating unbounded channels for now, as that was my use case. If you're interested we may be able to add support for bounded and zero channels, but there is AFAIK no risk in keeping an incomplete API here.

Please let me know if there is anything you need from me to get this merged faster, be it documentation, tests, etc.
Cheers :)

[ryoqun]

hey, this api is interesting to me as well.

Obviously this method cannot appear in the API of channel flavours like tick or never, since the point of those is to expose only a receiver. This means, we need two different types for Receiver. I put that new API in a separate submodule so that it's easy to import and document. That submodule only supports creating unbounded channels for now, as that was my use case. If you're interested we may be able to add support for bounded and zero channels, but there is AFAIK no risk in keeping an incomplete API here.

However, I didn't particularly like this submodule arrangement... How about making new_sender returning some dummy sender for tick and never? maybe this will be called full() or just disconnected() #1047 (comment)?

[ryoqun]

ping @oowekyala @taiki-e regarding my api idea: #750 (comment)