feat(*): Redis-backed revocation for stateless cookie sessions

[Hockenba]

Summary

Adds optional Redis-backed session revocation for stateless (cookie) sessions.

• On session:open, check whether the session ID is in the denylist.
• On session:destroy, write a lightweight sentinel to Redis with TTL matching remaining session lifetime (no session payload in Redis).

Revocation loads when storage is nil or "cookie" and Redis is configured for revocation (redis.mode = "revocation", or omitted mode with a redis.host). It can also be enabled explicitly via revocation = true or disabled with revocation = false.

revocation_fail_mode defaults to "open" (Redis unreachable → treat as not revoked; destroy still clears the cookie). "closed" rejects open/destroy when the store is unavailable.

Revocation applies to full destroy / single-audience logout. It does not apply to session:save rotation or partial multi-audience logout.

Consumer: apache/apisix#13651.

Test plan

• make unit / busted spec/06-revocation-1_spec.lua spec/07-revocation-2_spec.lua
• spec/06-revocation-1_spec.lua
  • Normal use: open, destroy+revoke, save rotation (no revoke), cookie-only destroy
  • Redis store: SET/GET, missing key, TTL expiry
  • Configuration: explicit/implicit redis.mode, redis storage skip, revocation=false, no host
• spec/07-revocation-2_spec.lua
  • Fail modes: default open, open destroy degrade, closed open reject, closed destroy fail
  • Validation: default revocation_fail_mode, redis+revocation mode reject, invalid revocation type
  • Redis connection failures on SET/GET

[bungle]

Great idea!

[bungle]

@Hockenba, I am wondering if this could be generic and work with all the storage backends. Not just Redis? And then you don't need to implement a revocation "interface" as it just seems to be using already defined storage ones.

[Hockenba]

@Hockenba, I am wondering if this could be generic and work with all the storage backends. Not just Redis? And then you don't need to implement a revocation "interface" as it just seems to be using already defined storage ones.

Agreed — we can probably make this generic so it works for all databases. I originally scoped it to Redis (with the rest as a TODO) since that’s all the APISIX plugin uses, but covering the others in this PR likely won’t take much extra work. I’ll look into it and follow up.

[Hockenba]

@bungle Closing this PR in favor of #209.

I am switching the source branch from geico:master to geico:feat/stateless-session-revocation. Our organization applies policies to master that make it impractical to keep long-lived feature work on that branch, so the remaining review and merge should happen from the feature branch instead.

Please continue review on the new PR. Title and description are unchanged aside from the link back to this thread.