Read every setting through viper and rename the settings (closes #211)

Every setting of waf and rproxy is read through viper, in place of the
os.LookupEnv function Main passed down. NewViper turns AutomaticEnv and
AllowEmptyEnv on, so a setting that is set but empty reads as set. A
setting may also be given as a file, the _FILE form, which rproxy's
settings now have too; rproxy still writes nothing to disk.

The settings are renamed: waf's take the prefix SWW_WAF_, rproxy's take
SWW_RPROXY_, and the shared SWW_COMMAND keeps SWW_. The Core Rule Set's
settings take SWW_WAF_CORE_RULE_SET_ rather than SWW_WAF_WAF_.

Model: deepseek-v4-pro (first version); opus-5-5 (rework)

docs/request-log.md

@@ -43,7 +43,7 @@ Every one of these lines has:
 
 - `time`: when `waf` had read the question's body, RFC 3339 with milliseconds,
   in UTC. The `report` line gives the same time as the `decision` line.
-- `instance`: `SWW_INSTANCE_NAME`.
+- `instance`: `SWW_WAF_INSTANCE_NAME`.
 - `client_ip`: the visitor's address, as `rproxy` worked it out.
 - `method`, `path` and `query`: the visitor's request.
 - `scheme`: how the visitor reached `rproxy` or the trusted proxy in front of
@@ -80,8 +80,8 @@ Every one of these lines has:
     - GeoJS had not answered by the time `waf` answered.
 - `content_type`: the visitor's `Content-Type`.
 - `content_length`: the body length the visitor announced.
-- `request_headers`: the headers listed in `SWW_LOG_REQUEST_HEADERS`, by name in
-  lower case.
+- `request_headers`: the headers listed in `SWW_WAF_LOG_REQUEST_HEADERS`, by
+  name in lower case.
 - `has_authorization` and `has_cookie`: true when the request had those headers.
   Their values are never logged.
 
@@ -94,8 +94,8 @@ Every one of these lines has:
 
 - `action`: what was done:
     - `forward`: answered `allow`, so that `rproxy` passes it to the app;
-    - `client_denied`: refused for `SWW_DENY_NETS`, for a reputation source with
-      the action `deny`, or for a tag in `SWW_TAG_DENY`;
+    - `client_denied`: refused for `SWW_WAF_DENY_NETS`, for a reputation source
+      with the action `deny`, or for a tag in `SWW_WAF_TAG_DENY`;
     - `temporarily_banned`: refused under a ban that runs out, or for a `ban`
       rule, a trap path or a CrowdSec decision that made such a ban;
     - `permanently_banned`: refused under a ban that never runs out, including a
@@ -112,21 +112,23 @@ Every one of these lines has:
   is left out when none did.
 - `heuristic_figures`: an object of the figures that heuristic acted on. Each
   heuristic and its figures:
-    - `deny_nets`: `netblock`, the entry of `SWW_DENY_NETS` the client is in;
+    - `deny_nets`: `netblock`, the entry of `SWW_WAF_DENY_NETS` the client is
+      in;
     - `active_ban`: `netblock`, the ban's netblock, and `ban_expires`;
     - `countries`: `country`, and `setting`, the country list that refused it;
-    - `tag_deny`: `tag`, the tag of `SWW_TAG_DENY` the request carries;
+    - `tag_deny`: `tag`, the tag of `SWW_WAF_TAG_DENY` the request carries;
     - `blocklists`: `lists`, the blocklist URLs that list the client;
     - `crowdsec`: `scenario`, the decision's scenario, and `expires`, when the
       decision ends;
     - `dnsbl`: `zones`, the DNS blocklist zones that list the client, their keys
       masked;
-    - `abuseipdb`: `score`, and `min_score`, `SWW_ABUSEIPDB_MIN_SCORE`;
+    - `abuseipdb`: `score`, and `min_score`, `SWW_WAF_ABUSEIPDB_MIN_SCORE`;
     - `rate_limits`: `window`, `count` and `limit`;
     - `trap_paths`: `path`, the trap path asked for;
     - `rule_files`: `rule_id` and `rule_action`, of the rule that refused it;
     - `header_limits`: `fields`, `fields_limit`, `cookies` and `cookies_limit`;
-    - `core_rule_set`: `score`, and `threshold`, `SWW_WAF_ANOMALY_THRESHOLD`;
+    - `core_rule_set`: `score`, and `threshold`,
+      `SWW_WAF_CORE_RULE_SET_ANOMALY_THRESHOLD`;
     - `refusal_limit`: `window`, `count` and `limit`, of the error burst;
     - `byte_limits`: `window`, `count` and `limit`, the count in bytes.
 - `after_answer_heuristic`: the heuristic that banned the client after `waf`
@@ -146,7 +148,7 @@ Every one of these lines has:
   holds:
     - `minute`, `hour` and `day`: requests;
     - `minute_bytes`, `hour_bytes` and `day_bytes`: the body bytes
-      `SWW_BYTES_COUNT` names, in that window.
+      `SWW_WAF_BYTES_COUNT` names, in that window.
 
     A count can have a fraction (see "Counting method" in
     [`SPEC.md`](../SPEC.md)). The bytes counted for an allowed request and its
@@ -156,7 +158,7 @@ Every one of these lines has:
 - `limit_hit`: the limit broken:
     - `minute`, `hour` or `day` for a rate limit;
     - `minute_bytes`, `hour_bytes` or `day_bytes` for a byte limit;
-    - `minute_refusals` for the error burst (`SWW_ERROR_BURST_THRESHOLD`).
+    - `minute_refusals` for the error burst (`SWW_WAF_ERROR_BURST_THRESHOLD`).
 
     When the bytes counted for a request and its response break a limit, the
     request has been passed on whole, so its `action` stays `forward`. Only its
@@ -174,7 +176,7 @@ Every one of these lines has:
 - `tags`: the request's tags, sorted, left out when it has none. Each tag and
   where it comes from is under "Request tags" in [`SPEC.md`](../SPEC.md).
 - `routewatch_tags_missing`: why the request got no tags from routewatch,
-  present only while `SWW_ROUTEWATCH_URL` is set:
+  present only while `SWW_WAF_ROUTEWATCH_URL` is set:
     - `no_answer_yet`: routewatch has not answered about this client yet;
     - `request_failed`: a query to routewatch failed within the last minute, and
       the process log says why;
@@ -231,13 +233,13 @@ meanings where they differ:
   was sooner. It includes the wait for `waf`.
 - `duration_response_ms`: milliseconds from then until the end of the answer.
 - `disposition`: what was done with the request: `allow`, `deny` or `close`. It
-  is `waf`'s answer, or the value of `SWRP_DEFAULT_DISPOSITION`. It is left out
-  when:
+  is `waf`'s answer, or the value of `SWW_RPROXY_DEFAULT_DISPOSITION`. It is
+  left out when:
     - `waf` was not asked, as for the health check;
     - the visitor went away while `waf` was being asked;
     - `waf`'s answer had no valid `X-Sww-Disposition`;
     - `rproxy` could not pass on `waf`'s answer, and answered `502`.
-- `default_disposition`: `true` when `SWRP_DEFAULT_DISPOSITION` gave
+- `default_disposition`: `true` when `SWW_RPROXY_DEFAULT_DISPOSITION` gave
   `disposition`, and otherwise left out.
 
 For example: