Status quo: We use OAuthRateLimiter to encode the user's (or application's) rate limits into the JWT. We then use Envoy's rate limit override function to apply them. The rate limits for each "tier" are configured in the $wgOAuthRateLimiterTierConfig variable, to mapping between applications and tiers is stored in the database.

Problem: Envoy's support for rate limit overrides is incomplete (for instance, they are not supported for per-route limits). Also, we are using a different system for the new JWT session tokens (T399198): where, the token defines the "rate limit class", which is used by Envoy to decide what limits to apply.

Proposal: Drop support for rate limit overrides and consolidate the two approaches. In the future, OAuthRateLimiter should put the rate limit class into tokens, instead of the actual limits. The limits currently configured in wgOAuthRateLimiterTierConfig would have to be moved to the gateway's rate limit configuration. This way, The gateway can just always take the rate limit class from the token and apply the configured limits for that class.

Old tokens that still have no rate limit calss would fall back to a class with restrictive limits, the embedded limit overrides would be ignored. Clients that encounter problems because of this will have to generate a new token.