Description
In the current design produce coroutine builder returns an instance of ProducerJob interface that extends ReceiveChannel and Job interfaces. The former gives access to all the channel operations, while the later contains Job-management API. Unfortunately, the Job is a CoroutineContext.Element and has operations like fold that operate on coroutine contexts. It clashes with the proposed extensions on ReceiveChannel that treats it as a sequence of elements with fold on them having a different meaning. See discussion in #88 for details.
So the proposal is deprecate ProducerJob and replace it with Producer interface that is a ReceiveChannel (to enable convenient pipelining) and has job as a property for cases where it is needed.
Now, the most common use-case for which you might need to access a producer's job is to cancel it when you don't need it. To make it easier, the proposal is to add cancel operation on ReceiveChannel interface directly. The semantics of cancel for a ReceiveChannel if that it signals that no more elements are going to be received from this channel and the producer of the channel must abort if it is still running (send will throw CancellationException). All the built-in pipelining operations like filter, map, etc on ReceiveChannel (see #88) are going to always cancel the receive channel when they are done (even if they crash), so this way an operational pipeline that starts with produce { ... } and continues with one of those pipelining operations will always cancel the producer without a risk of a producer leak if something crashes downstream.