Merge implementation with crossbeam-queue

[notgull]

From a brief glance at both crates, it seems to me that there is very little noticeable difference between the algorithm used in concurrent-queue and the one used in crossbeam-queue. It would be nice to just re-implement concurrent-queue in terms of crossbeam-queue if there are no/little significant differences between the two implementations, as it would deduplicate code in the Rust ecosystem.

[taiki-e]

IIRC, the main difference is the presence of code for the single-capacity cases (see also crossbeam-rs/crossbeam#199 (comment)) and disconnect(close) support.

[taiki-e]

I think there may also be a few optimizations that are present in crossbeam but not in concurrent-queue, such as crossbeam-rs/crossbeam#1057.

[james7132]

Would it be reasonable to add the one-shot optimization to crossbeam and deprecate this crate?

I've found that the enum inside this crate's representation leaves a bit to be desired in terms of both interface and performance as the match on every access results in a lot more codegen compared to crossbeam-queue, and extra unwraps/error handling when I know the queue is unbounded.

[notgull]

I would be fine with this as long as @taiki-e is

[james7132]

Looking at the benchmark results @taiki-e posted from before, not adding it also seems reasonable to me as well as other crates like oneshot exist for that exclusive use case, and we can just deprecate the crate.

[taiki-e]

What's actually needed to use crossbeam-queue in smol-rs is support for disconnect (aka close, needed for async-channel) and loom (needed for event-listener).

I'm open to accepting PRs to implement them.

As for single-capacity optimization, it seems further investigation is still needed, and for now, I think copying the implementation to async-channel instead of implementing it in crossbeam-queue is also fine.