ListRedisScheduleSource runs a full SCAN across the entire Redis keyspace on every update_interval

[tmkarthi]

The ListRedisScheduleSource currently runs a full SCAN across the entire Redis keyspace on every update_interval to discover past time keys. When Redis holds a large number of keys
(millions+), this becomes a significant bottleneck — it causes heavy CPU load on both Redis and the scheduler process, and the latency scales linearly with total key count regardless of how many
schedule keys actually exist.

[tmkarthi]

I've submitted a fix in #121 that eliminates the SCAN entirely by maintaining a {prefix}:time_index sorted set that tracks time keys as they're
created. On each poll, it uses ZRANGEBYSCORE to look up only the relevant past keys — an O(log N + M) operation where M is just the number of matching time keys, completely independent of total
Redis key count.

Key changes:

• No more SCAN — past time key discovery uses ZRANGEBYSCORE on the sorted set index
• Automatic bookkeeping — add_schedule adds to the index, delete_schedule triggers lazy cleanup of stale entries (rate-limited, with a 5-minute safety window to avoid race conditions)
• Zero-downtime migration — a populate_time_index=True flag lets existing users backfill the index with a one-time SCAN on startup, then disable it for all future runs
• Fixed a bug — in an extremely rare case, get_schedules could fetch current minute schedules twice if both get_schedules():current_time and _get_previous_time_schedules():minute_before point to the same minute.

All existing tests pass and 10 new tests cover the index lifecycle, cleanup behavior, and migration path. Would appreciate a review when you get a chance — happy to adjust anything.

[tmkarthi]

@s3rius Any update on this issue/PR?