Attempt fetch immediately when a queue is unpaused

[brandur]

Here, try to speed up the test suite by triggering a job fetch in the
producer when receiving a notice that a queue's been unpaused.

Currently, the "queue paused" example is by far the slowest test in the
entire project, clocking in at an impressive 1+ second:

$ go test . -count 1 -run Example_queuePause -test.v
=== RUN   Example_queuePause
Initial: 42ns
After start: 102.926042ms
Before pause: 109.6845ms
After pause: 109.879458ms
After insert: 112.385292ms
After reliable receive: 208.227042ms
After unreliable receive: 1.106444792s
After stop: 1.111110333s
--- PASS: Example_queuePause (1.11s)
PASS
ok      github.com/riverqueue/river     1.318s

(Extra timing information's been added to the test case above, but
notice how waiting for the receive from the unreliable queue after
unpausing it takes 800 ms+.)

The test's written in a way that it's hard to make it really fast, but
this change does succeed in more than doubling its speed:

$ go test . -count 1 -run Example_queuePause -test.v
=== RUN   Example_queuePause
Initial: 41ns
After start: 74.874791ms
Before pause: 77.679708ms
After pause: 83.262416ms
After insert: 88.872ms
After reliable receive: 177.465125ms
After unreliable receive: 276.994541ms
After stop: 284.25225ms
--- PASS: Example_queuePause (0.28s)
PASS
ok      github.com/riverqueue/river     0.516s

Because example tests have to run sequentially, that means we knock
about 800 ms off every run of the top level package's tests.

[bgentry]

I had a thought of how we could add coverage to this but it seems like it'd be pretty difficult and probably not worth it 🤔 This should work though!

[brandur]

I had a thought of how we could add coverage to this but it seems like it'd be pretty difficult and probably not worth it 🤔 This should work though!

Yeah, had the same thought. It'd be kind of nice, but hard to test properly and might bring in more intermittency. Hopefully this is reasonably unlikely to regress.