QUIC: Revisit QuicStream.ReadsComplete API

[geoffkizer]

We added this late in 6.0 to support ASP.NET requirements.

For 7.0, we should revisit the design here:

Instead of just a bool indicating whether reads are complete or not, we should consider also exposing whether the read side completed successfully (i.e. FIN) or was aborted -- and if so, what the QUIC error code was.

If we do that, it may make more sense to call this ReadStatus or something like that, and make it an enum.

We also may want to expose a similar WriteStatus property.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We added this late in 6.0 to support ASP.NET requirements.

For 7.0, we should revisit the design here:

Instead of just a bool indicating whether reads are complete or not, we should consider also exposing whether the read side completed successfully (i.e. FIN) or was aborted -- and if so, what the QUIC error code was.

If we do that, it may make more sense to call this ReadStatus or something like that, and make it an enum.

We also may want to expose a similar WriteStatus property.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	7.0.0

[geoffkizer]

A related issue is how to determine whether a QuicStream is bidirectional or unidirectional. Right now we are using CanRead and CanWrite for this. Maybe we should instead expose this via ReadStatus/WriteStatus if we expose properties like that? E.g. a enum value like ReadStatus = QuicStreamStatus.Invalid means the stream is write-only?

[ManickaP]

Closing as covered by #69675