servewaf answers rproxy's question about each request and takes its report (closes #170)

`smallwebwaf servewaf` runs today's checks on the visitor's request each
question carries, answers rproxy, and passes nothing to an app. rproxy reports
every request servewaf answered. A report counts an allowed request's bytes and
writes servewaf's second log line. The table holds a copy of what a report
needs, never the request, so a report cannot reach a request being handled.

Judgement call: a question's body is read before any check; over 64 KiB gets 400.
Judgement call: a report's bytes and durations have ceilings, so they cannot overflow.
Judgement call: a `close` disposition for SWWAF_BAN_RESPONSE=close.

Model: opus-5-5

docs/request-log.md

@@ -117,3 +117,65 @@ All in milliseconds:
   connection;
 - `duration_upstream_first_byte`: until the first byte of the answer;
 - `duration_upstream_total`: until the end of the answer.
+
+## `servewaf`'s lines
+
+`smallwebwaf servewaf` writes two lines for each question it answers, joined by
+`request_id`. The field `servewaf_line` says which of the two a line is:
+
+- `decision`: the line it writes once it has answered the question;
+- `report`: the line it writes when `rproxy`'s report comes, with everything
+  known. The repetition is intended.
+
+A request to its own endpoints writes one line, without `servewaf_line`. A
+report writes no line but the `report` line of the request it names.
+
+These questions write no line:
+
+- a question refused with `400` (see "The question" under "`servewaf`" in
+  [`SPEC.md`](../SPEC.md));
+- a question whose body stopped arriving, which gets no answer.
+
+### The `decision` line
+
+It has the fields above, with these meanings where they differ:
+
+- `client_ip`: `X-Smallwebwaf-Client`.
+- `peer_ip`: `X-Smallwebwaf-Peer`.
+- `host`: the site the visitor asked for.
+- `protocol`: the question's own, `HTTP/1.1`.
+- `content_length`: `X-Smallwebwaf-Content-Length`.
+- `request_id`: the question's `X-Request-ID`.
+- `status`: what `servewaf` answered: `200` for `allow`, the status of `deny`,
+  or `0` for `close`, as the visitor is then sent nothing.
+- `request_bytes`: how much of the question's body the Core Rule Set read.
+- `response_bytes`: the body of `servewaf`'s answer.
+- `action`: `forward` for `allow`, and `admin` for the `404` for a path under
+  `/_smallwebwaf/`.
+- `aborted`: true when `rproxy` went away before the answer.
+- `duration_total`: from the question's headers being read to the line.
+
+The line leaves out `upstream_status`, `websocket` and the
+`duration_upstream_...` fields, since `servewaf` passes nothing to the app.
+
+The bytes of an allowed request are counted when its report comes. So `counts`
+holds the client's bytes without this request's.
+
+### The `report` line
+
+It has every field of the `decision` line, and `time` stays when the request
+arrived. These fields say what the report says:
+
+- `status`: what the visitor got, `0` if nothing;
+- `request_bytes` and `response_bytes`: the body bytes each way, with what a
+  WebSocket carried each way;
+- `duration_total`: from the request's headers being read by `rproxy` to the end
+  of the answer;
+- `duration_upstream_total`: from the hand-over to the app to the end of the
+  answer, for an allowed request.
+
+For an allowed request, the report's counting also changes these fields:
+
+- `counts`: the byte totals now include this request's;
+- `limit_hit`, `offence` and `ban_expires`: set when the report's bytes broke a
+  byte limit.