Support per-rule actions and SECCOMP_FILTER_FLAG_NEW_LISTENER loading

[lu-zero]

Summary

Make SeccompAction::UserNotif (added in #95) usable in hybrid filters,
where different syscalls take different actions in one filter. SeccompFilter
applies a single match_action to every rule today; this adds per-rule actions
and a loader for SECCOMP_FILTER_FLAG_NEW_LISTENER.

Motivated by fakeroost#7,
which routes stat through a USER_NOTIF pool while keeping writes on TRACE —
previously requiring hand-rolled BPF. Reference port:
fakeroost#8.

Relationship to #75

#75 (colinmarc, stalled since Apr 2025) adds a Notify variant + a loader but
not per-rule actions — it can't express "syscall A → Notify, syscall B → Trace"
in one filter, which is the gap this PR fills. #95 already merged UserNotif
unconditionally, superseding #75's feature-gated Notify. Our loader
(apply_filter_with_listener) overlaps #75's apply_filter_with_notify_fd; happy
to adopt that name if preferred.

Changes

• SeccompRule gains action: Option<SeccompAction>; None falls back to the
  filter's match_action (existing usage unchanged). New constructors
  new_with_action (conditions + action) and always (unconditional). First
  matching rule wins; append_syscall_chain emits the rule's own RET.
• validate() relaxed: a condition-less rule is valid iff it carries an action.
• apply_filter_with_listener() -> Result<OwnedFd> installs with NEW_LISTENER
  (Linux 5.0+) and returns the listener fd. Separate from
  apply_filter_with_flags (rc contract differs: positive rc = fd, not TSYNC).
• new_with_action(vec![], ..) now returns Err(EmptyRule) — previously it
  silently behaved like always.

SeccompAction::UserNotif is intentionally unit: the kernel ignores the
return-data bits for SECCOMP_RET_USER_NOTIF, so a u32 would be a tag it
discards (unlike Errno/Trace). See docs/design-per-rule-actions.md.

Testing

New unit + integration tests for the above; 36 tests / 5 suites pass,
clippy -D warnings clean, fmt clean. fakeroost's integration suite passes
on this branch (#8).

Open questions (none block this draft)

1. IdenticalActions is over-strict when every rule overrides.
2. JSON frontend has no per-rule action field yet (non-breaking).
3. No notification consumer API; low-level bindings are landing in libc
   (#5224); a high-level
   supervisor API would be a separate crate.

Draft to gather feedback — especially on reconciling with #75 — before
finalizing.

[rbradford]

I like the idea of being able to specify specific actions for different rules but I think this commit is overloaded with too many disparate changes. Please split the work.

[rbradford]

Please make the CI pass.

[lu-zero]

It should be fine now

[lu-zero]

Is there anything needed to change?

[alindima]

Seems sensible but I wouldn't bundle it with the changes for supporting SECCOMP_FILTER_FLAG_NEW_LISTENER as I don't think they're related in any way.

Also, I'd like to see some integration tests as well for the per-rule actions

[lu-zero]

Do you prefer a PR per-commit? I'll prepare them and add some more tests.

[alindima]

Do you prefer a PR per-commit? I'll prepare them and add some more tests.

not neccessarily one commit per PR but I'd rather have them bundled only if they are related in some way. These are completely different features

[lu-zero]

Now it is split in #102 and #103