TcpStream always terminates connections successfully (even on panic)

[pdolezal]

@jbe

Variant 1

• panics cause an "abort" (according to RFC 793),
• calling TcpStream::shutdown with Shutdown::Write or Shutdown::Close cause a "close" (according to RFC 793),
• a new method will be provided to allow an explicit abort, such as TcpStream::abort,
• dropping a TcpStream cause a "close" by default (ensures backward compatibility and also avoids data loss such as when error messages are sent to the peer before dropping the stream),
• it's possible to switch the default drop behavior to "abort" by calling something like TcpStream::abort_on_drop() (useful for error handling with the "?" operator).

@jbe

Variant 2

• panics cause an "abort" (according to RFC 793),
• dropping the TcpStream causes an "abort" as well,
• in order to achieve a graceful "close" (send an EOF to the peer and flush data out), the connection must be closed explicitly by calling a new method, something like TcpStream::close, possibly with an optional timeout parameter that indicates how long the operating system should attempt to flush data out.

I like Variant 2 more, but it might be just because I don't see breaking the existing behavior as a big deal (considering that the current behavior does not seem completely right to me). Perhaps, to mitigate the behavior change, there might be some methods to tune the options of the connection, including how it should behave on drop (or panic), while the defaults would ensure the current behavior.

Anyway, I definitely support a kind of close method for explicit graceful and possibly fallible termination of a resource. In cases like this it would allow to confirm that the connection was closed gracefully and with no error. In a little different context, I found a use case for such a method.