fix(worker): fix bzpopmin race condition

[Marsup]

Why

As explained in #2619, the resolution order of setTimeout and bzpopmin under certain conditions is wrong.

How

To reestablish the correct order, I'm scheduling the disconnection for the next tick to let bzpopmin eventually resolve properly.

Additional Notes (Optional)

I'm honestly not sure how to add non-regression testing on this, I'd like some advice on this if possible.

I also removed the async modifier of the timeout callback, not really sure why it was there.

[manast]

This feels like hitting the can down the road instead of actually resolving the possible underlying issue, although I am not convinced yet there is any issue :/

[Marsup]

I don't like that solution myself either, but I know it works, and it'll probably keep working for the foreseeable future. The only alternative would be for ioredis to go into the microtask queue to go 1st, but I haven't been able to figure out in the driver why it was queuing itself after the other timers.

[manast]

I don't like that solution myself either, but I know it works, and it'll probably keep working for the foreseeable future. The only alternative would be for ioredis to go into the microtask queue to go 1st, but I haven't been able to figure out in the driver why it was queuing itself after the other timers.

It is solving your particular symptom, however as it is not fully clear what is the issue it is not really solving it.