fix(perf): improve delete_from_sorted_set speed

[mhenrixon]

Closes #835

[ezekg]

For delete_from_sorted_set, using ZSCAN still has the same time complexity of O(N) as the previous usage of ZRANGE (i.e. at worst case, when adding to the end of the queue — a typical workload when scheduling jobs into the future — it iterates the entire queue), which is where the problem lies. If the sorted set were, for example, 1,000,000 items instead of 100,000, the performance test would fail even worse. The entire purpose of my PR was to use ZRANGE BYSCORE to limit that search space so that we never iterate the entire queue, because iterating the entire queue won't ever scale. Right now, your solution to use ZSCAN still has the same fundamental problem: it doesn't scale; you just pushed the work to iterate the entire queue onto Redis.

Also, your tests are passing because you aren't running performance tests in CI. It fails locally for me:

bin/rspec --require spec_helper --tag perf --fail-fast spec/performance/unique_job_on_conflict_replace_spec.rb
# => Run options: include {:focus=>true, :perf=>true}
# 
#    Randomized with seed 34288
#    
#    UniqueJobOnConflictReplace
#      when schedule queue is large
#        locks and replaces quickly (FAILED - 1)
#    
#    Failures:
#    
#      1) UniqueJobOnConflictReplace when schedule queue is large locks and replaces quickly
#         Failure/Error:
#           expect do
#             Timeout.timeout(0.1) do
#               described_class.perform_in(2_592_000, 100_000, { "type" => "extremely unique" })
#             end
#           end.not_to raise_error
#    
#           expected no Exception, got #<Timeout::Error: execution expired> with backtrace:
#             # /home/zeke/.rvm/gems/ruby-3.2.2/gems/redis-client-0.20.0/lib/redis_client/ruby_connection/buffered_io.rb:139:in `wait_readable'

[ezekg]

More thoughts: for the worst case — where the string we're searching for doesn't exist in the set — ZSCAN performs better, since it's non-blocking vs an iterative ZRANGE over the set. But when the string does exist — and we have its score — using ZRANGE BYSCORE will be orders of magitude faster because it divides the search space.

So, I guess I have 2 major questions that need answering to fully understand the problem:

1. Do we know if the digest (a) MAY exist or that it (b) WILL exist in the sorted set?
2. Is the score you mentioned already storing always accurate?

If the answer to 1 is (b) it MAY exist, then maybe we can try to find the item by score using ZRANGE BYSCORE at first, but fall back to ZSCAN for the worst case where the ZRANGE BYSCORE returned no results (indicating our score is stale, or the digest doesn't exist). If the answer to 1 is (a) it WILL exist, then ZRANGE BYSCORE will always be faster, given 2.