Consider a specialized split fn for TcpStream

[carllerche]

The type can safely support a read and a write task without coordination.

[vojtechkral]

@carllerche I would like to have a look at this as part of my work. I've posted an (ugly) workaround in #1108. Also related is #852 - the split could easily handle connection shutdown, which could make a lot of TcpStream use cases simpler.

Do you have preferences as to how this should be structured and/or other design constraints before I start writing a PR?
Is this also applicable to UnixStream and UdpSocket?

[carllerche]

Yes, probably.

Incidentally, I think not calling TcpShutdown in Sink shutdown was probably a mistake.

[carllerche]

I think this may require some changes to PollEvented. I have not thought that Koch about it yet but now is a good time to explore as we can issue breaking changes.

[vojtechkral]

Also related: #824 & #774 . Seems like the same underlying problem keeps popping up :-) I thought this might be an opportunity for me to familiarize with Tokio & mio a bit, perhaps with some mentoring if that's fine? (Or is the change too fundamental for that?)

I'm only reading the implementation so far. Seems like PollEvented & Registration is sort of ready for the indepentend reading & writing screnario, but this might be at odds with ownership, since I/O needs mut access...