Middle-class of haproxy rate-limit bypass
We've heard of a prospect (https://gitlab.my.salesforce.com/0064M00000VrN8e - internal only) that would have 10K-15K users accessing gitlab.com from behind 4 IP addresses (proxied). Even our planned 2K/min/IP limit on /api in haproxy will probably not be sufficient for this (0.5 req/user/minute to /api, assuming perfect distribution of users and requests across the 4 IPs.
Our only knob right now is to grant them an IP-based bypass of the haproxy rate-limits, which then also implies a RackAttack bypass.
Therefore I propose a second class of bypass, that bypasses haproxy rate-limtiing but does not set the header allowing RackAttack to do authenticated per-user rate-limiting. I suspect this to be relatively simple to implement (haproxy configuration only), and is a nice middle-ground of trust, rather than extending a legacy full-bypass to new customers.
For bonus points we could create tiers of these classes, with actual higher limits in haproxy (rather than a bypass), although it's quite possible any useful numbers we place on those would still be so trivially abused that we may as well just trust the customers and let RackAttack do its thing.