Monitor specific queue for long wait if configured

[jasonmccreary]

This is a proposed solution for #1171 to monitor a specific queue if configured.

Currently, when running multiple queues an event is emitted for that "shared" queue. So there's no way to be notified when a specific queue within a "shared" queue has a long wait.

This PR allows you to receive an event for a specific queue, even if running within a multiple queue, when configured via waits.

For example:

    'waits' => [
        // ...
        'redis:automation' => 1800,
    ],

    // ...

    'environments' => [
        'worker' => [
            'shifts' => [
                // ...
                'queue' => ['automation', 'subscriber', 'paid', 'workbench'],
                'balance' => false,
            ],
        ],
    ],

In an effort to be backwards compatible, I did not change the underlying WaitTimeCalculator. Instead, I isolated the change to the listener. It now also monitors any queues configured via waits. This actually provides more flexibility as you may now monitor individual and multiple queues, but potentially combinations of queues which may not run under the same supervisor (would need more testing).

Combined with #1172, I hope this makes the waits configuration more robust for developers needs.

[jasonmccreary]

Please help me with my cascading comment and collection pipeline. 😅

[taylorotwell]

But is this actually the correct wait times? Maybe it was like this intentionally. If you have a queue worker working "foo, bar, baz, qux" queues... that means it will work the all of the other queues to empty before it processes ANY jobs from "qux". Meaning the wait time for qux would have to be the summation of the prior queues as well.

You can see that logic in the prior code.

[jasonmccreary]

@taylorotwell, yes, that may be correct. I was trying to avoid changing the WaitTimeCalculator for fear of a breaking change.

In the end, this desired feature is really know which queue, in a multiple queue, might have a long wait time. I may need to add a new method to determine that.

[jasonmccreary]

After toying around a bit, there isn't a way to determine the wait time for a specific queue in a shared queue or multiple supervisor configuration without making some assumptions, and therefore not provide an accurate wait time.

As such, I am closing this PR.