Redefine aliases for LimitedQueue

[jahfer]

👋🏼 I stumbled into this bugfix by only partially reading the documentation 😅

I was playing with Async::LimitedQueue, but called #pop on it (which is technically not documented), and it completely hung. Reason being that the @full notification doesn't fire on #pop because it's referring to the implementation on Async::Queue rather than using Async::LimitedQueue#dequeue, which correctly signals @full.

As a fix, I redefined the aliases in Async::LimitedQueue so they pick up the redefinitions. Without the changes, the updated tests will completely hang in the #pop case.

I also noticed the original test for this wasn't actually working because #contain_exactly wasn't defined, and so the async block containing the assertions was being completely ignored. I couldn't get the structure of what was there prior to work (even with switching to #have_value), so I asserted based on the dequeued values instead. No strong opinion on this :)

Types of Changes

• Bug fix.

Contribution

• I added tests for my changes.
• I tested my changes locally.
• I agree to the Developer's Certificate of Origin 1.1.

[ioquatix]

TBH, aliases and sub-classes are kind of confusing in Ruby leading to behaviour like this. Thanks for the PR, I think it looks okay, but I might replace the aliases with direct dispatch (e.g. def <<(...); self.push(...); end)

[ioquatix]

FYI, I'm slowly leaning away from using Async::Queue and so on. During Async v1, they were useful, but in Async v2, I believe it is just better to use Thread::Queue and so on. Althought, while I have not tested it, there may be a small performance advantage to using Async::Queue etc.

[ioquatix]

Okay, I did this: a91f32c