Bug: Redis fallback ack_deadline_ms does not work as expected

[jaymell]

This setting does not work as expected. The issue is that when messages are received, they are moved from the main queue to the processing queue without updating their ID, so that a message will potentially be re-enqueued based on the time it was created rather than the time it was last received.

This has the potential to result in duplicate messages and/or messages that are re-queued too soon if they are not acked within ack_deadline_ms from the time they were originally enqueued.

Currently we do an atomic BRPOPLPUSH in order to move items from the main queue to the processing queue. We will probably need a non-atomic solution that involves popping a message and enqueuing it into the processing queue with a new ID if we want to fix this.