Fix Rate Limiting for Cloud Environments

[viceda-s]

Problem: The current IP rate limiter uses request.getRemoteAddr(), which returns the Load Balancer's IP in cloud environments, effectively sharing one rate limit across all global users.

Acceptance Criteria:

• Update IpRateLimitFilter to extract the client IP using the X-Forwarded-For header.
• Fallback to getRemoteAddr() only if the header is missing.
• Write a unit test simulating requests with and without the X-Forwarded-For proxy header.

[viceda-s]

• 1. Update IpRateLimitFilter to extract the client IP using the X-Forwarded-For header.
  Done! Added the getClientIp method which extracts and sanitizes (in case of multiple IPs) the exact value from the X-Forwarded-For header.

• 2. Fallback to getRemoteAddr() only if the header is missing.
  Done! The getClientIp method includes the condition if (xfHeader == null || xfHeader.isEmpty() || "unknown".equalsIgnoreCase(xfHeader)) which immediately calls request.getRemoteAddr() as a safe fallback.

• 3. Write a unit test simulating requests with and without the X-Forwarded-For proxy header.
  Done!

• With header: The new test doFilterInternal_WithXForwardedFor_UsesClientIP simulates a complex string ("203.0.113.195, 10.0.0.1") and ensures that the Rate Limit ignores the internal proxy (10.0.0.1) and correctly consumes tokens for the public IP (203.0.113.195).

• Without header: The pre-existing test (doFilterInternal_Unauthenticated_NoTokens_Returns429) does not mock the header and continues to pass, proving that the fallback to request.getRemoteAddr() (which returned "192.168.1.1") works perfectly.

Closing this issue.