feat: implement EWMA rate limiter with strategy support (#404)

[saniddhyaDubey]

Description

Implements an Exponentially Weighted Moving Average (EWMA) rate limiter as the new default strategy, replacing the sliding window approach. The EWMA algorithm stores only two values per key (rate and timestamp) in a Redis hash, making it significantly more memory-efficient than the sliding window which stores every request in a sorted set. The entire EWMA calculation is handled atomically via a Lua script in Redis, preventing race conditions.

Related Issue

#404

Motivation and Context

The sliding window rate limiter stores every request timestamp in a Redis sorted set, causing memory usage to grow linearly with traffic. For high-traffic relays with thousands of concurrent clients, this becomes a primary cost driver. EWMA solves this by maintaining only two values per key regardless of traffic volume, while still accurately penalizing bursty behavior through exponential decay.

How Has This Been Tested?

• Unit tests — added unit tests for calculateEWMA covering first request, burst behavior, time decay, and long inactivity scenarios
• Integration test — added a Cucumber integration test that pre-seeds Redis with a rate value above the limit, sends a WebSocket event, and verifies the relay correctly responds with a rate limited notice
• Manual testing — ran the relay locally with Docker Compose, verified EWMA hash keys (rate and timestamp fields) are correctly stored and updated in Redis on each request, and confirmed rate limiting triggers under load

Screenshots (if appropriate):

End-to-end EWMA rate limiting verification:

• left terminal shows wscat receiving NOTICE: rate limited after exceeding the message limit
• top-right shows server logs confirming Using strategy: ewma,
• bottom-right shows Redis hash with rate and timestamp fields being updated in real time on each request, confirming EWMA is storing decay state correctly.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• All new and existing tests passed.