feat(framework): adopt request attributes and remove CycleState

[szedan-rh]

Parent

Sub-issue of #221
Depends on #287 (Phase 1 imports — merged)

Summary

Adopt EPP's principle of using request attributes as the single source of truth for plugin data sharing, replacing the current CycleState pattern.

Context

Per discussion with @nirrozenbaum: follow EPP's principles where PluginState is explicitly not a cross-plugin handoff channel — data shared between plugins flows through request attributes. For IPP's use case, PluginState (requestID-scoped, janitor cleanup) is likely unnecessary since CycleState is already created fresh per-request and discarded after. Request attributes can serve as the single source of truth.

Changes

1. Add attributes on InferenceRequest

• Give InferenceRequest an AttributeMap so plugins can write/read structured data there
• Follow EPP's pattern: per-request attribute store

2. Migrate current CycleState usages to request attributes

• Move cross-plugin keys (e.g. session-affinity/session-id, selected model) to request attributes
• Each plugin writes its data to request attributes instead of CycleState

3. Remove CycleState

• Once all data flows through request attributes, remove CycleState from plugin interfaces
• Remove CycleState parameter from all plugin method signatures (Filter, Score, Pick, ProcessRequest, ProcessResponse, etc.)
• Delete cycle_state.go

Acceptance criteria

• InferenceRequest has an AttributeMap for plugin data sharing
• All cross-plugin data flows through request attributes
• CycleState removed from all plugin interfaces and implementations
• make test passes
• make lint passes

[nirrozenbaum]

how would plugins exchange state if needed?

[szedan-rh]

In the EPP, PluginState is intentionally per-plugin, per-request — it's not a cross-plugin handoff channel. Cross-plugin data sharing in EPP flows through the Producer/Consumer DAG: plugins write to Endpoint.AttributeMap (per-endpoint data) or to InferenceRequest attributes (per-request data).

In IPP today, CycleState serves both roles: intra-plugin coordination AND cross-plugin state sharing. The EPP split is cleaner architecturally, but adopting it fully means:

1. Intra-plugin state (e.g., session-affinity storing a session ID to read later in the same plugin) -> PluginState
2. Cross-plugin state (e.g., model selector storing the selected model for downstream response handlers) -> flows through the InferenceRequest or AttributeMap, not through plugin state

However, IPP's current CycleState is created fresh per-request and discarded after there's no requestID scoping or janitor cleanup needed since the lifecycle is already bounded. So the practical question is whether we need to adopt EPP's PluginState structure or just align the types (StateKey, StateData) while keeping our simpler per-request model.

I think to start with aligning FactoryFunc (json.RawMessage → *json.Decoder with StrictDecoder) and importing shared types (StateKey, StateData, ErrNotFound). Keep CycleState's simple per-request lifecycle for now, it's sufficient for IPP's use case. The cross-plugin state question can be addressed if/when we adopt the Producer/Consumer pattern from EPP.

WDYT? @nirrozenbaum

[nirrozenbaum]

I think it would be good to follow the same principles from EPP.
we need to first add attributes on the request before removing CycleState.
I'm also wondering if PluginState is really needed, or we can use request attributes as the single source of truth (a plugin can write it's information and read from there)

[szedan-rh]

Agree, request attributes as the single source of truth is cleaner and aligns with EPP's own guidance (PluginState docs explicitly say "not a cross-plugin handoff channel; data shared between plugins must flow through AttributeMap").
For IPP's use case, I think you're right that PluginState may not be needed at all. IPP creates a fresh CycleState per request and discards it after — there's no long-lived state that needs requestID scoping or janitor cleanup. If we move the cross-plugin data (selected model name, session ID, etc.) to request attributes, the remaining intra-plugin state is just local variables within a single method call.

[szedan-rh]

PR: #294 raised