Allow closing one half of the request/reply streams pair.

[flub]

On a request/replay stream/sink pair for individual RPCs it should be possible to close one half while still keeping the other half open.

An example of this would be a watch call, which is a single message as request and a stream of responses. After the client makes the request it should be able to close the channel making it clear no more messages will be sent to the server. Likewise, and more important, the server would do the same: after reading the request it closes the request stream ensuring the client can no longer send any messages on the request stream.

This would be analogous to e.g. quinn::RecvStream::stop or sn2_quic::stream::ReceiveStream::stop_sending (and their send stream equivalents).

[rklaehn]

I am not quite sure what this would be useful for. Can you describe a use case?

This is just a substream, so closing one half of a substream does not mean that anything can be closed on the transport level. You still need bidirectional communication for other substreams. So what does it give you, other than a guarantee that there won't be any more messages?

Guarantees about the number of messages etc. are handled not on a channel level but in the higher level DSL. E.g. when you use the RPC interaction pattern you know that there is going to be 1 req -> 1 res, and anything else will produce an error that you don't have to care about.

[flub]

The watch command is a nice usecase here. I don't really like that the current impl of watch races receiving a second message and errors out. It would be much nicer if that half of the pipe is stopped and the sender simply can't send stuff anymore.

This is a little nicer than just ignoring that half of the channel: if you ignore it the sender can still fill all the buffers. If you stop it both the sender and receiver will drop any buffers.

[rklaehn]

I think the benefit of having a single primitive - a bidirectional stream - for all interaction patterns is quite nice. It simplifies the code a lot and makes it possible to have vastly different transports (quinn, s2n_quic, http2, and the very important mem transport).

Since keeping a substream open in both directions has no high cost, and improper use is properly handled, I don't quite see the benefit.