Replace custom Deque implementation with swift-collection Deque

[FranzBusch]

Motivation

For AsyncStream we created a custom internal Deque implementation to use for the buffering. This implementation was relatively bare-bones compared to the one in swift-collections. Furthermore, it lacked some methods that we need to implement the new AsyncStream APIs that support producer backpressure.

Modification

This PR copies over the Deque implementation of swift-collections and makes it internal and non-inlinable.

Result

We now have a fully functional Deque.

[FranzBusch]

@swift-ci please test

[FranzBusch]

@swift-ci please smoke test

[ktoso]

LGTM about getting the swift-collection's deque.

This keeps it internal so that's fine, but maybe prepare a pitch as well to make it part of stdlib? It is used all over the place being copied around 🤔 WDYT @lorentey ?

If we intend to keep this copy around like this though, would it be good to automate copying the files a bit so it is easier to keep the two impls in sync? Or working towards removing the one in swift-collections in favor or a public pitched one from the stdlib.

[FranzBusch]

Yeah it would be great if we could get Deque officially moved into the stdlib. It is the one type that I consistently reach for in every AsyncSequence implementation.

[ktoso]

Up to @lorentey to give the thumbs up or down here perhaps.
But yeah this type would definitely be useful in concurrency library even for our internals

[lorentey]

Yes, this is clearly an interim solution. Manually vendoring these implementations into every single ABI stable OS component is not going to be a good approach in the long term.

The big blocker for adding Deque as a public stdlib type is that there is a really good chance that Swift's incoming ownership features will render the implementation obsolete in a few months (years?) -- so we'd probably regret if we baked its current layout into the ABI right now.

Until we're ready to do that though, this is the best we can do! 👍 Mechanically copying a known-good implementation is better than having multiple parallel reimplementations of the same thing.

[lorentey]

I recommend adding prominent comments at the top of source files pointing to their upstream location, to try prevent things from diverging too much from upstream.

In case the _Concurrency module ends up needing to make substantial changes/fixes to this code, those ought to be propagated back into the swift-collections package.

[ktoso]

Thanks for the detailed thoughts @lorentey! Looks good then.

Maybe a README or something in the Deque directory pointing at https://github.com/apple/swift-collections/tree/main/Sources/DequeModule could do it as well?

[FranzBusch]

@swift-ci please smoke test

[FranzBusch]

@swift-ci please test

[FranzBusch]

@swift-ci please smoke test

[FranzBusch]

@swift-ci please test

[FranzBusch]

@swift-ci please test macos

[FranzBusch]

@swift-ci please smoke test

[FranzBusch]

@swift-ci please test

[FranzBusch]

@swift-ci please smoke test

[FranzBusch]

@swift-ci please test macos