Say which bytes the byte limits count, and what passing one does (closes #203)

The byte limits and the byte anomaly thresholds count body bytes, as
SWW_BYTES_COUNT chooses them, once a response has ended; the request
that takes a client past a limit is passed on whole, and the client is
banned. README.md, SPEC.md and docs/settings.md now say so where they
said "bytes a client's requests may carry". Also made plain: a request
past a rate limit is refused and bans the client; SWRP_MAX_REQUEST_TIME_MS
is two consecutive limits; SWW_LOOKUP_SOURCE's three values; and the
claim that discriminator always answers within SWRP_TIMEOUT_MS, which
the spec itself contradicts.

Model: fable-5-1

SPEC.md

@@ -184,11 +184,12 @@ request log's `heuristic` field gives that name. `refusal_limit` and
     sent is removed.
 15. After the visitor's answer has ended, `rproxy` sends the report (see "The
     report"). `discriminator` then counts:
-    - For a request it allowed, the response bytes, the request bytes or both
-      are added to the byte counters, as `SWW_BYTES_COUNT` says. For a
-      WebSocket, what it carried each way counts once it closes. A client whose
-      total passes a byte limit times the percentage has broken that limit and
-      is banned (`byte_limits`). The response in progress is not cut off.
+    - For a request it allowed, the body bytes of the response, of the request
+      or of both are added to the byte counters, as `SWW_BYTES_COUNT` says. For
+      a WebSocket, what it carried each way counts once it closes. A client
+      whose total passes a byte limit times the percentage has broken that limit
+      and is banned (`byte_limits`). The request that broke it has already been
+      passed on whole; nothing is cut off.
     - For a request it allowed, the client's history and the anomaly counters
       are updated, and the alert thresholds are evaluated.
 
@@ -251,7 +252,7 @@ to a ban, each by its own rule:
       clear sign of attack bans it permanently at once.
 - A broken limit, one of:
     - a request over a rate limit;
-    - a response that takes the client's byte total past a byte limit;
+    - a request whose body bytes take the client's total past a byte limit;
     - more than `SWW_ERROR_BURST_THRESHOLD` refusals within a minute.
 
     The bans for a broken limit:
@@ -439,10 +440,13 @@ the same way.
 
 ### Byte limits, per client
 
-By default there is no minute limit, so a client can download in a burst at full
-speed. The hour limit defaults to 50 GiB and the day limit to 100 GiB. They
-allow several downloads of a few GiB each. A response's bytes are counted when
-it ends (see step 15).
+The byte limits count body bytes: the app's response bodies, the visitors'
+request bodies, or both, as `SWW_BYTES_COUNT` says. Headers are never counted. A
+request's bytes are counted once its response has ended (see step 15). So the
+request that takes a client past a limit is passed on whole, and the ban refuses
+the client's requests from then on. By default there is no minute limit, so a
+client can download in a burst at full speed. The hour limit defaults to 50 GiB
+and the day limit to 100 GiB. They allow several downloads of a few GiB each.
 
 ### Lookup of AS number and country
 
@@ -905,7 +909,8 @@ which the metrics show. They reveal a widely distributed scraper, thousands of
 addresses at low rates each, which the per-client limits do not see. A low
 `SWW_ASN_LIMIT_PERCENT` for its AS number is the response.
 
-- Requests and bytes are counted per minute and per hour, for each of:
+- Requests and body bytes, as `SWW_BYTES_COUNT` counts them, are counted per
+  minute and per hour, for each of:
     - a client;
     - the surrounding netblock;
     - an AS number;
@@ -1215,9 +1220,9 @@ short.
 ### Answering in time
 
 `rproxy` stops waiting for `discriminator` after `SWRP_TIMEOUT_MS`, by default 2
-seconds, and `SWRP_DEFAULT_DISPOSITION` then decides. So at the defaults,
-`discriminator` answers a request well within that time, whatever the request
-and whatever its outside sources do.
+seconds, and `SWRP_DEFAULT_DISPOSITION` then decides. So the longest a question
+waits on an outside source, `SWW_LOOKUP_TIMEOUT`, is by default well within that
+time, whatever the source does.
 
 GeoJS is the only outside source a question can wait on. A question waits only
 when step 5 says so, and for at most `SWW_LOOKUP_TIMEOUT`, by default 800
@@ -1313,9 +1318,9 @@ answer.
 For a request it holds, `discriminator` writes the request's last log line (see
 "The log"). For a request it allowed, it first:
 
-- counts the bytes as `SWW_BYTES_COUNT` says, toward the client's byte limits at
-  the percentages it gave that request;
-- bans a client that passes a byte limit;
+- counts the body bytes `SWW_BYTES_COUNT` names, toward the client's byte limits
+  at the percentages it gave that request;
+- bans a client whose total passes a byte limit;
 - adds the request with its status to the client's history, the anomaly counters
   and the metrics.