CheckRateLimit Counters in response

[eguzki]

Following the introduction of the new CheckRateLimit gRPC method in #430, we have an opportunity to provide richer feedback to rate-limited clients.

service RateLimitService {
  // Determine whether a request should be allowed or denied based on rate limiting rules.
  rpc CheckRateLimit(envoy.service.ratelimit.v3.RateLimitRequest) returns (envoy.service.ratelimit.v3.RateLimitResponse); 
}

I propose that the counters are loaded to include fields that carry standard rate-limiting metadata. Specifically, this would align with the IETF Rate-Limit Headers draft, providing values for:

• RateLimit-Limit: The request quota in a given time window.

• RateLimit-Remaining: The number of requests remaining in the current window.

• RateLimit-Reset: The time remaining until the quota resets.

A key driver for this feature is the Token Rate Limit Policy workflow. In this scenario, a gateway (like Envoy or an API gateway) calls the CheckRateLimit service. By including these standard values in the gRPC response, the gateway can easily extract them and add them as HTTP headers to the final response sent to the original client.

This provides a standardized, transparent way to inform clients about their rate limit status, improving the developer experience.