Determine Stream drop behavior

[camshaft]

From comment: #129 (comment)

Matthias247

Btw: I learned that Quinn implements dropping a stream as closing it instead of resetting it. That seems like an option to get around the UNKNOWN issue. However I am not sure if I prefer it, since it seems like it could close the stream even if not all expected data is sent.

camshaft

Yeah I could go either way on it. I think if we want to be close to what TCP streams do in Rust it would probably be better to finish it rather than reset.

From https://doc.rust-lang.org/std/net/struct.TcpStream.html

The connection will be closed when the value is dropped. The reading and writing portions of the connection can also be shut down individually with the shutdown method.

From tokio-rs/tokio-io#73 (comment)

the intention of shutdown was for things like "shut down the TLS connection" or "flush remaining buffers and then shut down the underlying socket" or things like that, the name shutdown wasn't intended to convey a literal TCP shutdown and was a mistake on our part.

[Matthias247]

I'm basically OK either way as long as it's documented.

However I agree that it could make sense to do what the other implementations do and prefer a close over a reset

[camshaft]

Streams are finished on drop without error