[proxy] replace the batch cancellation queue, shorten the TTL for cancel keys

[conradludgate]

See #11942

Idea:

• if connections are short lived, they can get enqueued and then also remove themselves later if they never made it to redis. This reduces the load on the queue.
• short lived connections (<10m, most?) will only issue 1 command, we remove the delete command and rely on ttl.
• we can enqueue as many commands as we want, as we can always cancel the enqueue, thanks to the intrusive linked lists BTreeMap.

[github-actions]

8492 tests run: 7911 passed, 0 failed, 581 skipped (full report)

---

Code coverage* (full report)

• functions: 32.0% (9033 of 28222 functions)
• lines: 48.4% (80362 of 166198 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
02cd4c1 at 2025-06-20T11:31:58.011Z :recycle:}

[awarus]

Looks way better than we had before. Nevertheless, I think we should run it in staging with some prod-like load before releasing

[conradludgate]

Yeah, I at least ran it in staging to verify the cancellation works after 10 minutes (it does work). We would need to hit it with high connection request rate to verify (I can give that a go in a moment)

[conradludgate]

I'll merge now so it stays in staging. I'll run some tests (useful now that we can edit our rate limits :D)