Make reason for try_send errors clearer

[jonhoo]

When you call try_send on a channel and the call fails, it often matters to the caller why the call failed. For unbounded senders, we know that it must be because the receiver went away, whereas for bounded channels it may either be because the receiver went away or because there was no available capacity. This PR explicitly calls out in the docs that errors on UnboundedSender::try_send can only occur if the channel receiver has gone away, and adds was_closed and was_full methods to the error returned by BoundedSender::try_send so the caller can figure out which of the two error cases they're in.

[jonhoo]

I just noticed that is_closed is called is_disconnected in futures::sync::mpsc. Not sure if it's worth renaming + deprecating to match the code people are coming from?

[LucioFranco]

@jonhoo I saw that too, I am in favor of keeping the api roughly the consistent, and it seems this api is still the case in futures 0.3 as well.

[jonhoo]

Along the same lines, it may be that we want oneshot::Sender::poll_close to poll_cancel (and similarly rename is_close to is_cancelled). That might be a more controversial change though, as poll_close aligns better with things like Sink.. :/

@carllerche ^

[ghost]

Related issues on "close" vs "disconnect":

• Close vs disconnect in futures-channel rust-lang/futures-rs#1346
• Breaking changes before releasing crossbeam-channel 1.0 crossbeam-rs/crossbeam#256 (comment)

I wish the whole community just chooses one of those two words and sticks to it. :)