Centralize Redis Client Usage and Add Caching in LeaderboardService

[gabito1451]

Description

This PR introduces a singleton Redis client via a global RedisModule and integrates it into the existing LeaderboardService to enable caching of leaderboard queries. This improves performance by reducing redundant database queries and ensures consistent Redis usage across the application.

• Redis client is injected via the custom REDIS_CLIENT token.
• Caching is applied in getLeaderboard() with a 60-second expiration.
• Redis read/write errors are gracefully handled with logs.
• No new DTOs were added; cached data is typed as any[] to avoid unsafe any warnings.
• Existing functionality of LeaderboardService is preserved without modifications to other providers.

Changes

• Inject Redis client into LeaderboardService constructor.
• Modify getLeaderboard() to:
  • Check Redis cache first using a composed cache key.
  • Parse and return cached data if available.
  • Query the leaderboard service on cache miss.
  • Cache fresh results with expiration.
• Add try/catch blocks around Redis operations to handle connection or runtime errors.
• Update imports to include Redis and REDIS_CLIENT.

How to Test

1. Ensure Redis is running locally or configured via .env with REDIS_URL.
2. Start the NestJS app.
3. Call leaderboard endpoints or methods to trigger caching.
4. Observe Redis cache hits by inspecting logs or directly querying Redis.
5. Confirm leaderboard data is returned correctly with or without cache.
6. Shut down app gracefully to verify Redis disconnect (if implemented).

Notes

• This PR focuses solely on caching inside LeaderboardService; other services remain unaffected.
• The Redis client lifecycle is managed globally in the RedisModule.
• For type safety, cached data is returned as any[] due to lack of a dedicated DTO.
• Future improvements could include cache invalidation on leaderboard updates.

[phertyameen]

Great contribution.