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>

internal/engine/inputs.go

@@ -39,6 +39,13 @@ const (
 	OpBlockRuleDelete = "blockrule.delete"
 	OpBlockingPause   = "blocking.pause"
 
+	OpBlockStepCreate   = "blockstep.create"
+	OpBlockStepUpdate   = "blockstep.update"
+	OpBlockStepDelete   = "blockstep.delete"
+	OpClientGroupCreate = "clientgroup.create"
+	OpClientGroupUpdate = "clientgroup.update"
+	OpClientGroupDelete = "clientgroup.delete"
+
 	// Requests only: disabling and enabling records, by ID or by match
 	// (zone, name, type and optionally data), become record.update
 	// operations.
@@ -50,7 +57,8 @@ const (
 var OpKinds = []string{OpZoneCreate, OpZoneUpdate, OpZoneDelete, OpRecordCreate, OpRecordUpdate, OpRecordDelete, OpRRSetReplace,
 	OpViewCreate, OpViewUpdate, OpViewDelete, OpViewReorder, OpACLCreate, OpACLUpdate, OpACLDelete,
 	OpTSIGCreate, OpTSIGUpdate, OpTSIGDelete, OpOptionCreate, OpOptionUpdate, OpOptionDelete, OpSettingsUpdate,
-	OpBlocklistCreate, OpBlocklistUpdate, OpBlocklistDelete, OpBlockRuleCreate, OpBlockRuleUpdate, OpBlockRuleDelete, OpBlockingPause}
+	OpBlocklistCreate, OpBlocklistUpdate, OpBlocklistDelete, OpBlockRuleCreate, OpBlockRuleUpdate, OpBlockRuleDelete, OpBlockingPause,
+	OpBlockStepCreate, OpBlockStepUpdate, OpBlockStepDelete, OpClientGroupCreate, OpClientGroupUpdate, OpClientGroupDelete}
 
 // Request is an operation as submitted by a client. Requests are expanded
 // into one or more stored operations (for example an A record with "ptr"
@@ -236,6 +244,31 @@ type BlocklistInput struct {
 	ViewIDs  *[]int64  `json:"view_ids,omitempty"`
 	Disabled *bool     `json:"disabled,omitempty"`
 	Comment  *string   `json:"comment,omitempty"`
+	// Step is the step the list starts at, by name ("normal" or a step
+	// above it) or ID (StepID; 0 is normal).
+	Step   *string `json:"step,omitempty"`
+	StepID *int64  `json:"step_id,omitempty"`
+}
+
+// BlockStepInput creates or updates a blocking step above Normal.
+// Position orders the steps (new steps go on top).
+type BlockStepInput struct {
+	Name     *string `json:"name,omitempty"`
+	Position *int    `json:"position,omitempty"`
+	Comment  *string `json:"comment,omitempty"`
+}
+
+// ClientGroupInput creates or updates a client group. Members are
+// addresses, prefixes or ACL names; the step is given by name ("off",
+// "normal" or a step) or ID; views as for BlocklistInput.
+type ClientGroupInput struct {
+	Name    *string   `json:"name,omitempty"`
+	Members *[]string `json:"members,omitempty"`
+	Step    *string   `json:"step,omitempty"`
+	StepID  *int64    `json:"step_id,omitempty"`
+	Views   *[]string `json:"views,omitempty"`
+	ViewIDs *[]int64  `json:"view_ids,omitempty"`
+	Comment *string   `json:"comment,omitempty"`
 }
 
 // BlockRuleInput creates or updates a block or allow rule. Views as for