Make Async Request Body actually work

[0xTim]

The existing implementation of adding an AsyncSequence to Request.Body had two issues:

• it didn't ensure code was being called from the correct event loop which broke Sendable guarantees and was unsafe
• it would hit a precondition failure in the implementation if backpressure was triggered because the initial state was not accounted for

This fixes that

Resolves #3088

[codecov-commenter]

Codecov Report

Merging #3096 (4dd939f) into main (3bf4e73) will increase coverage by 0.10%.
Report is 2 commits behind head on main.
The diff coverage is 95.83%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3096      +/-   ##
==========================================
+ Coverage   76.23%   76.34%   +0.10%     
==========================================
  Files         211      211              
  Lines        7904     7918      +14     
==========================================
+ Hits         6026     6045      +19     
+ Misses       1878     1873       -5     

Files	Coverage Δ
...ces/Vapor/Authentication/AuthenticationCache.swift	84.84% <100.00%> (+0.97%)	⬆️
Sources/Vapor/Authentication/Authenticator.swift	57.89% <ø> (ø)
Sources/Vapor/Authentication/GuardMiddleware.swift	100.00% <ø> (ø)
...rces/Vapor/Authentication/RedirectMiddleware.swift	83.33% <ø> (ø)
Sources/Vapor/Request/Request+BodyStream.swift	96.66% <100.00%> (+0.37%)	⬆️
...ources/Vapor/Concurrency/Request+Concurrency.swift	59.79% <87.50%> (+8.14%)	⬆️

[MahdiBM]

Looks as good as it could be to me

[MahdiBM]

We could just use AsyncAlgorithms's var async, but not sure if it's fine to add a dependency to that just for this test.
That also takes Task cancellation into account which we don't want, but this is in tests and that's not going to happen anyway.
https://github.com/apple/swift-async-algorithms/blob/5bbdcc1d37990cca524852c5a3924c02fa2da983/Sources/AsyncAlgorithms/AsyncSyncSequence.swift#L46C5-L46C5

[gwynne]

Honestly I think adding an entire "this uses code from ..." mess etc. etc. and all this format boilerplate is a hell of a lot of overkill for a test to begin with. The logic here is just not involved enough to merit the effort. I mean for pity's sake, look at what happens when you yank all the noise, it's literally nothing but another layer of boilerplate:

struct AsyncLazySequence<Base: Sequence & Sendable>: AsyncSequence, Sendable {
    typealias Element = Base.Element
    struct AsyncIterator: AsyncIteratorProtocol, Sendable {
        var iter: Base.Iterator
        mutating func next() async throws -> Base.Element? { self.iter.next() }
    }
    var base: Base
    func makeAsyncIterator() -> AsyncIterator { .init(iter: self.base.makeIterator()) }
}
extension Sequence where Self: Sendable { var async: AsyncLazySequence<Self> { .init(base: self) } }

(Also can I just point out that the @available annotations are completely meaningless in this context? Like, triply so. And the @inlinable annotations are equally worthless in a test, since it's not optimizing compilation.)

[0xTim]

Yeah I cut it down significantly. There are a few other options and the best way to do this would be Async Algorithm but it's a test and this was the quickest easiest thing!

[penny-for-vapor]

These changes are now available in 4.86.2