unbuffered: After `Closed` no `WriteTraffic` state arrives about rustls

[ctz]

Thanks for the report. Yes, the current API treats a half-close as a full-close. I think we should add additional ConnectionStates so the server in your example can finish its connection with:

• ReadTraffic reads the client's close_notify
• PeerClosed informs the application that no further data will be forthcoming from peer
• WriteTraffic for additional server-sent traffic, followed by queue_close_notify
• EncodeTlsData for outputting that data
• TransmitTlsData for confirming the data was sent
• Closed nothing further can happen with this connection

(This arrangement retains Closed as a terminal, full-close state.)

[uazu]

Thanks for the quick response. There is no rush from my point of view as I also have it working with the buffered interface, and I can continue to use that. So if it's a breaking change for 0.24 that's not a problem. The API changes you suggested sound fine, but I'll code against whatever you come up with. If you want me to test against a pre-release version of Rustls I can do that.

Also it would be helpful to have some guidance about buffer-sizing requirements, either in the docs or as API calls. For example I'm allowing 18KiB for EncodeTlsData because that appears to be the maximum required by protocol, but typically it will be much less. I can add another issue for this if you wish.

[djc]

Will this need semver-incompatible changes? If so, it might take us a while to get this released.

[cpu]

The ConnectionState enum is non_exhaustive so adding new states there isn't semver breaking in itself. I think it would be more a question of how the semantics of the overall API are updated and whether it affects existing usages.