transports/tcp/: Call take_error on tokio TcpStream

[mxinden]

Description

See e04e95a for the rational.

With tokio v1.19.0 released, TcStream exposes take_error.

This commit applies the same fix from e04e95a to the tokio TCP provider.

Links to any relevant issues

Corresponding merged pull request for the async-std side: #2458

Tokio pull request: tokio-rs/tokio#4739

Open Questions

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[dignifiedquire]

looking at fn writable this seems to be doing sth different than what connect_mio calls under the hood

poll_fn(|cx| stream.io.registration().poll_write_ready(cx)).await?;

vs

 pub async fn writable(&self) -> io::Result<()> {
    self.ready(Interest::WRITABLE).await?;
    Ok(())
}

[mxinden]

Correct. I was following the recommendation in the last paragraph of the poll_write_ready docs:

    /// Polls for write readiness.
    ///
    /// If the tcp stream is not currently ready for writing, this method will
    /// store a clone of the `Waker` from the provided `Context`. When the tcp
    /// stream becomes ready for writing, `Waker::wake` will be called on the
    /// waker.
    ///
    /// Note that on multiple calls to `poll_write_ready` or `poll_write`, only
    /// the `Waker` from the `Context` passed to the most recent call is
    /// scheduled to receive a wakeup. (However, `poll_read_ready` retains a
    /// second, independent waker.)
    ///
    /// This function is intended for cases where creating and pinning a future
    /// via [`writable`] is not feasible. Where possible, using [`writable`] is
    /// preferred, as this supports polling from multiple tasks at once.

https://github.com/tokio-rs/tokio/blob/55078ffec3bba78803ff646f3933a23834789e4e/tokio/src/net/tcp/stream.rs#L793-L807

Do you see any problems with that @dignifiedquire?

[dignifiedquire]

I see, that makes sense, seems like using writable is the right call to make here 👍