Investigate if async reader/async writer and their concluding variants should be sendable

[czechboy0]

Investigate if async reader/async writer and their concluding variants should be sendable.

The concrete case when you hit it is when calling requestConcludingAsyncReader.consumeAndConclude { reader in and need to send the reader.

[gjcairo]

I don't think this would be correct. At least for the readers: they're basically wrappers for async iterators, which can't safely be sendable.

[adam-fowler]

In the early days of Sendable I made the RequestBody in Hummingbird Sendable and regretted it later. It opens up paths to multiple tasks iterating the request body concurrently which is not good.

[czechboy0]

cc @FranzBusch who suggested I file this issue when we investigated the API together. I think this came up while trying to bridge to other systems that required capturing the reader in a @sendable closure, and the API predates Swift 6.0, so no sending etc were an option.

[czechboy0]

Actually, I double checked and it wasn't a Sendable closure, it was needing to wrap the reader in a sendable async sequence.

[FranzBusch]

I agree that the reader and writer should not be Sendable. They are ~Copyable so they can only be owned by one thing at a time; however, they can still be put into a class box. If the reader and writer are Sendable then the box can easily become Sendable as well without the need of @unchecked. This would lead to a problem since we expect our readers and writers to be used non-concurrently.

Having said that. It would be good to investigate if we can pass those two as sending instead so users can move them into a child task without errors.