Implement support for latest draft of RFC for HTTP rate limiting headers

There is an Internet Draft for the IETF standards track to support rate limiting headers in HTTP.

It would be great to support these in our gateway before it becomes a standard. The current draft is probably close enough to the final text that we can start work on it (this URL contents' will be updated over time):

https://ioggstream.github.io/draft-polli-ratelimit-headers/draft-polli-ratelimit-headers.html

This is not by any means a full solution for API management and the specification leaves enough room to define what quota "units" mean, as well as not guaranteeing that they are exact or even very close to the actual usage allowed (or even that you can't consume more than the value specified). The headers are meant as a hint on what the limits are expected to be to the best knowledge of the service, and are not scoped to specific paths (even though we can certainly do that).

For the general case in 3scale we can provide information about the actual endpoint (method) being consumed and the remaining hits until a certain time. If there is no limit, we will not specify the headers, and if there is, we should specify the most constrained limits: the sooner period with the lowest remaining value of the applying limits, ie. if we have limits of 60 hits/minute and 180 hits/hour but we have consumed 150 hits in previous minutes for the current hour, and 0 in the current minute (still included in the hour), and the first request in this current minute is received, say 10 seconds in, then the response could return 30 units remaining (if 1 request means 1 unit is consumed) and reset after 50 (seconds).

If, for example, we would have one hit to a specific endpoint increase in 2 the method counters, then we can still model that easily, since we return units and not requests in the header.

Note that if we are hitting a metric with no limits but the parent metric has, the headers should still be provided, because limits (the parent's) are still in effect.

A full solution for 3scale is out of scope for this draft and this issue. A future I-D might build on this one to address scoping and/or other necessities for more fine-grained rate limiting.

About the implementation:

In apicast we might want to implement this as our own code providing the headers. There is the possibility of upstreaming code exclusively for configured endpoints in nginx, which necessarily means a focus on infrastructure. But if we ever do that, or if nginx ever provides that, we could ensure (ie. patch) that support provides a hook to inform such code of what the API management layer thinks the limits are.