Adopt omniqueue as a queue backend and remove our own in-memory queue implementation

[svix-jplatte]

Depends on #1185 (merged), svix/omniqueue-rs#24.

I have deleted low-level tests for the in-memory queue since its basic functionality should be tested inside omniqueue, not here. Do we have tests for higher-level functionality that uses the in-memory queue backend in some scenarios?

The redis and SQS implementation should probably be replaced by the implementations found in Omniqueue in a follow-up PR, to keep this one reasonably small.

[svix-james]

LGTM, but somebody who was a bit more invested in the development of omniqueue than me should probably chime in.

[svix-onelson]

Hm, even with the unbounded mpsc channel that the builtin in-memory queue used now adopted in omniqueue, some tests are still failing consistently, and with a super weird error message:

thread 'test_uid_across_users' panicked at library/alloc/src/raw_vec.rs:570:5:
capacity overflow

Plus a connection reset that I assume comes from the panic propagating up to hyper, which subsequently terminates the connection that the panicked task was serving.

@svix-jplatte did this get solved somehow?

[svix-onelson]

LGTM

[svix-jplatte]

Yes, there was one place where usize::MAX was passed as a buffer / channel capacity. I just put in a 128 instead, I doubt the exact number matters much since the in-memory queue isn't supposed to be optimized right?

[svix-onelson]

in-memory queue isn't supposed to be optimized right?

Correct. It's more of a stub than anything else. Like a dummy (no-op) cache implementation.