Addition of API throttling

[josephdenne]

The ability to throttle all methods on the basis of requests over time. This should be globally enforceable, as well as configurable on a per client and per collection basis.

For example, 10 GET requests every second.

[eduardoboucas]

Some notes on this while the thought is fresh:

• Global configuration: this should be relatively simple. We need to add a new configuration property and read from it on every request.

• Per-collection configuration: this could be part of the settings block of the collection schema, overriding the global value. Not sure where this stands when we move collection schemas to the database, it probably still works.

• Per-client configuration: this one is a bit more tricky. We could store rate limits against the client record, but that would mean reading from it on every request, which we currently avoid doing for performance reasons. We could explore the possibility of encoding rate limits on the JWT token payload, meaning that we wouldn't have to hit the database to know the rate limits for a particular client before processing a request. The only downside of this is that it wouldn't be possible to update the rate limits for a given client during the lifecycle of a token – i.e. the new settings would only take place once the client requested a new bearer token. This might be fine if documented, as people can configure the token TTL to this effect.

[josephdenne]

Global rate limiting is really for us, whereas collection and client rate limiting is for customers. So the former is more important than the latter in the near term.