Filter pipeline architecture: phases, dependencies, BodyMode convergence

[shaneutt]

Architectural improvements to the filter pipeline.

• Filter dependency declarations (read/write context fields) with startup validation
• Phase system (auth, routing, upstream, observe) when 5+ ordering constraints accumulate
• Converge StreamBuffer and Buffer into a single Buffer mode with unified delivery semantics
• FilterAction::SkipRemaining for short-circuit without reject

[usize]

One capability that fits naturally here: per-filter failure modes (fail-open / fail-closed).

We're looking at using Praxis in models-as-a-service and kagenti-extensions, which currently depend on Envoy. Both projects — and the wg-ai-gateway payload processing proposal — require configurable failure modes per filter. MaaS sets failure_mode_allow: false on its ext_proc guardrails filter, but observability filters in the same chain should fail open.

Today any Err(FilterError) propagates immediately and results in a 500 — every filter is implicitly fail-closed with no per-filter override. Adding an optional failure_mode field to FilterEntry (defaulting to closed for backwards compat) would cover this:

filter_chains:
  - name: inference
    filters:
      - filter: ext_auth
        failure_mode: closed   # reject on error (default)
        grpc_address: "authorino:50051"
      - filter: ext_proc
        failure_mode: closed   # guardrails must not be bypassed
        grpc_address: "payload-processing:9004"
      - filter: access_log
        failure_mode: open     # don't block requests if logging fails

This also means #17 and #14 get failure modes for free at the pipeline level rather than each reimplementing their own. Fits well with the phase system too — phases could set defaults (auth = closed, observe = open) with per-filter overrides.

Happy to work on this if you'd like a PR.

[shaneutt]

Sounds good, added a sub-task for this 🖖