Add queue clearing logic to the Redis migrations

[svix-daniel]

As a followup to #671, this change adds logic like the Redis migration functions which clears the queue of acknowledged, stale tasks up to the lowest pending ID. This is run every thirty seconds until there has been a successful trimming of tasks.

The following is a brief explanation of how Redis streams work:

If you XREADGROUP it'll be added to the PEL (pending entries list) and thus show up in XPENDING until it has been XACKed. But it'll never show up in XREADGROUP with that specific consumer group again.

Once XACK ed it removes the reference in the PEL, and will show up in neither XPENDING or XREADGROUP.

It will however remain in the stream and show up via XREAD regardless of whether it is ACKed, but we don't do this anywhere. We instead use XAUTOCLAIM on items that have been read but not XACKed for more than 45 seconds and reinsert them into the queue.

While it doesn't show up in XREADGROUP, it's still there consuming memory until the item has been XDELed from the stream.

The bug was that we would XACK tasks, but not XDEL them at any point up until the changes of #671. However, #671 only fixes tasks that are acknowledged after updating the server instance. This PR is meant to clear stale queue tasks that were acknowledged before updating.

The approach here is to use XPENDING to get the lowest ID that has been read but not ACKed (knowing the server reads from the stream by order of entry), and to XTRIM up to that point exclusive. Should there be no items in the XPENDING return, then the logic will loop with a 30 second delay until there are entries in the PEL at the time of reading. This is an imperfect solution, but it is still likely that the PEL will have at least one entry within a reasonable amount of time given a high-load queue.

Given there isn't high load and XPENDING never returns a non-empty array, it is assumed that this bug has not consumed enough memory to make clearing the queue automatically a great necessity.