Add leader election for Reaper high availability

[mcollina]

Summary

• Implement Redis-based leader election so multiple Reaper instances can run for high availability, with only one active at a time
• Uses SET NX PX pattern for atomic lock acquisition with TTL
• Leader renews lock periodically; if it crashes, lock expires and a follower takes over
• Graceful shutdown releases lock immediately for fast failover

Changes

• Add optional acquireLeaderLock, renewLeaderLock, releaseLeaderLock methods to Storage interface
• Implement lock methods in RedisStorage using Lua scripts for atomicity
• Refactor Reaper with #becomeActive()/#becomeInactive() lifecycle methods
• Add leadershipAcquired and leadershipLost events
• Add comprehensive test suite for leader election scenarios

Usage

const reaper = new Reaper({
  storage,
  visibilityTimeout: 30000,
  leaderElection: {
    enabled: true,              // Default: false (backward compatible)
    lockTTL: 30000,             // Lock expiry (default: 30s)
    renewalInterval: 10000,     // Renew every 10s
    acquireRetryInterval: 5000  // Followers poll every 5s
  }
})

reaper.on('leadershipAcquired', () => console.log('Now leader'))
reaper.on('leadershipLost', () => console.log('Lost leadership'))

Test plan

• Run existing Reaper tests to ensure backward compatibility
• Test single reaper with election enabled acquires lock
• Test two reapers - only one becomes leader
• Test leader shutdown - follower takes over
• Test lock renewal works across TTL periods
• Test error handling when storage doesn't support leader election

🤖 Generated with Claude Code