Different blocking for different devices: steps and client groups

Client groups put devices (addresses, networks, or ACLs of them) at a
blocking step: off (only your rules), normal (the default), or steps
added above it, each including the lists of the steps below. Lists
start at a step. In each view, a gate policy zone in front of a step's
lists lets the devices below that step through (rpz-client-ip triggers
with rpz-passthru), so every list is still loaded once. The IPv6 part
of a gate leaves the IPv4-mapped range out: named matches IPv4 clients
as ::ffff:a.b.c.d.

Web UI: a Devices panel on the Blocking page and a step on each list.
CLI: jarl block step, jarl block group, jarl blocklist --step. API:
/blocking/steps, /blocking/groups. Database schema 8.

Also: copying the state kept empty lists as empty (not nil), so
reverting a changeset no longer adds restore operations for unchanged
blocklists, rules and views.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -17,7 +17,8 @@ All notable changes to Jarl are documented here. The format follows
 - The systemd unit changed (it allows `AF_NETLINK`). The package replaces
   it; an override that adds `AF_NETLINK` (`systemctl edit jarl`) does no
   harm and can be removed.
-- The database moves to schema 7 (disabled zones) as jarld starts.
+- The database moves to schema 8 (disabled zones, client groups) as
+  jarld starts.
 - If statistics showed a spike after views were created or changed, see
   "Statistics" under Fixed: the bad minutes can be removed from
   `/var/lib/jarl/stats.db` (minute rows have `res = 'm'`; the hours and
@@ -25,6 +26,16 @@ All notable changes to Jarl are documented here. The format follows
 
 ### Added
 
+- Different blocking for different devices (docs/blocking.md), like
+  Pi-hole's groups, in one view and without loading any list twice.
+  Client groups put devices (addresses, networks or ACLs of them) at a
+  blocking step: `off` (only your rules), `normal` (the default), or steps
+  you add above it, each including the lists of the steps below. Lists
+  start at a step. Jarl puts a small "gate" policy zone in front of each
+  step's lists that lets the devices below that step through. Web UI: a
+  Devices panel on the Blocking page and a step on each list. CLI: `jarl
+  block step`, `jarl block group`, `jarl blocklist update --step`. API:
+  `/blocking/steps`, `/blocking/groups`. Database schema 8.
 - View keys: every view gets a TSIG key, `jarl-view-NAME`, at the front of
   its match-clients, so a query signed with it lands in that view from any
   address. Jarl signs its delegation check's queries to this server's own
@@ -140,6 +151,9 @@ All notable changes to Jarl are documented here. The format follows
 
 ### Fixed
 
+- Reverting a changeset added needless "restore" operations for
+  blocklists, rules and views that hadn't changed: copying the state
+  turned their empty view lists into missing ones.
 - Under the shipped systemd unit, jarld couldn't list the host's
   addresses (it needs a netlink socket, which `RestrictAddressFamilies`
   didn't allow), so the name server checks didn't recognize this server's