discriminator: the header limits are the first check (closes #311)

A request over 50 cookies or 100 header fields is now refused before any
other check. It causes no lookup, no query to RouteWatch, a DNS blocklist
or AbuseIPDB, no rule file match and no Core Rule Set. The rate limits no
longer count it, and a banned or denied client gets 431 for it. In observe
mode no lookup is made for it. Requests within the limits go through the
same checks in the same order.

Model: opus-5-5

README.md

@@ -511,7 +511,7 @@ of the request reaches the app.
 
 `discriminator` takes the checks:
 
-3. The tag lists.
+3. The header limits, then the tag lists.
 4. The static lists, `SWW_ALLOW_NETS` and `SWW_DENY_NETS`.
 5. The bans.
 6. The lookup of the client's AS number and country.
@@ -523,7 +523,7 @@ of the request reaches the app.
 11. The rate limits.
 12. The trap paths.
 13. The rule files.
-14. The header limits, and then the Core Rule Set.
+14. The Core Rule Set.
 15. The tag refusals again, so that `exploitsignature` can refuse too.
 16. A path under `/_sww/` is answered `404`, so that the app never sees that
     prefix.
@@ -539,7 +539,7 @@ of the request reaches the app.
 A refused visitor is answered with `SWW_BAN_RESPONSE`. A `block` rule or a Core
 Rule Set match answers `403` and bans nobody, since the Core Rule Set has false
 positives; such refusals count toward `SWW_ERROR_BURST_THRESHOLD` instead. A
-request over the header limits of step 14 is answered `431`, and bans nobody
+request over the header limits of step 3 is answered `431`, and bans nobody
 either. `rproxy` itself answers `405` to a method it does not pass on, and the
 status for a size or time limit, such as `413` for a body too large.