message: [channel] clean up channel logic and comment
  As the related mpsc channel fix is merged to upstream and we bumped
  futures to 0.3.0-alpha.17, the related channel logic and comments can be removed.
diff: //! Provides an mpsc (multi-producer single-consumer) channel wrapped in an
  //! [`IntGauge`](metrics::IntGauge)
  -//!
  -//! The original futures mpsc channels has the behavior that each cloned sender gets a guaranteed
  -//! slot. There are cases in our codebase that senders need to be cloned to work with combinators
  -//! like `buffer_unordered`. The bounded mpsc channels turn to be unbounded in this way. There are
  -//! great discussions in this [PR](https://github.com/rust-lang-nursery/futures-rs/pull/984). The
  -//! argument of the current behavior is to have only local limit on each sender, and relies on
  -//! global coordination for the number of cloned senders. However, this isn't really feasible in
  -//! some cases. One solution that came up from the discussion is to have poll_flush call poll_ready
  -//! (instead of a noop) to make sure the current sender task isn't parked. For the case that a new
  -//! cloned sender tries to send a message to a full channel, send executes poll_ready, start_send
  -//! and poll_flush. The first poll_ready would return Ready because maybe_parked initiated as
  -//! false. start_send then pushes the message to the internal message queue and parks the sender
  -//! task. poll_flush calls poll_ready again, and this time, it would return Pending because the
  -//! sender task is parked. So the send will block until the receiver removes more messages from the
  -//! queue and that sender's task is unparked.
  -//! [This PR](https://github.com/rust-lang-nursery/futures-rs/pull/1671) is supposed to fix this in
  -//! futures 0.3. It'll be consistent once it's merged.
  -//!
  -//! This change does have some implications though.
  -//! 1. When the channel size is 0, it becomes synchronous. `send` won't finish until the item is
  -//! taken from the receiver.
  -//! 2. `send` may fail if the receiver drops after receiving the item.
  -//!
  -//! let (tx, rx) = channel::new_test(1);
  -//! let f_tx = async move {
  -//! block_on(tx.send(1)).unwrap();
  -//! };
  -//! let f_rx = async move {
  -//! let item = block_on(rx.next()).unwrap();
  -//! assert_eq!(item, 1);
  -//! };
  -//! block_on(join(f_tx, f_rx)).unwrap();
  -//!
  -//! For the example above, `tx.send` could fail. Because send has three steps - poll_ready,
  -//! start_send and poll_flush. After start_send, the rx can receive the item, but if rx gets
  -//! dropped before poll_flush, it'll trigger disconnected send error. That's why the disconnected
  -//! error is converted to an Ok in poll_flush.
  use futures::{
  channel::mpsc,
  @@ -84,21 +47,12 @@ impl<T> Sink<T> for Sender<T> {
  Ok(())
  }
  - // `poll_flush` would block if `poll_ready` returns pending, which means the channel is at
  - // capacity and the sender task is parked.
  fn poll_flush(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
  - match (*self).value.poll_ready(cx) {
  - Poll::Ready(Err(ref e)) if e.is_disconnected() => {
  - // If the receiver disconnected, we consider the sink to be flushed.
  - Poll::Ready(Ok(()))
  - }
  - x => x,
  - }
  + Pin::new(&mut self.value).poll_flush(cx)
  }
  - fn poll_close(mut self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
  - self.value.disconnect();
  - Poll::Ready(Ok(()))
  + fn poll_close(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
  + Pin::new(&mut self.value).poll_close(cx)
  }
  }
  