Description

This PR adds two new options to the proxy-cache plugin and tightens how the in-memory cache strategy treats upstream Cache-Control response directives.

New options

• consumer_isolation (boolean, default: true). When the request resolves to an APISIX consumer (ctx.consumer_name) or carries a remote user (ctx.var.remote_user), the identity is prepended to the effective cache key so each consumer gets its own cache namespace. The augmentation is skipped when the user-supplied cache_key already references an identity-bearing variable ($consumer_name, $consumer_group_id, $remote_user, or $http_authorization). Set to false for routes where consumers should share cached responses.
• cache_set_cookie (boolean, default: false). The in-memory and on-disk strategies refuse to cache responses that include a Set-Cookie header unless explicitly opted in. Set-Cookie is per-recipient and not generally safe for a shared cache to store.

Behavior change

The in-memory strategy now always honors upstream Cache-Control: private, no-store, and no-cache directives, regardless of the existing cache_control flag. The cache_control flag continues to govern request-side semantics (client Cache-Control request directives such as max-age / min-fresh / only-if-cached) and TTL derivation from max-age / s-maxage. This matches the behavior of NGINX's native proxy_cache (used by the on-disk strategy) and brings the two strategies into closer agreement.

Backward compatibility

The new defaults change behavior in three ways for users who have proxy-cache enabled today:

1. Routes that combine proxy-cache with an authentication plugin will start partitioning the cache by consumer. Existing cache entries become unreachable; new entries accumulate per consumer. Set consumer_isolation: false to opt out.
2. The in-memory strategy will no longer cache responses that include Set-Cookie. Set cache_set_cookie: true to opt back in.
3. The in-memory strategy will no longer cache responses whose upstream Cache-Control includes private, no-store, or no-cache, irrespective of the route-level cache_control flag.

Each is independent; users can mix and match opt-outs.

Which issue(s) this PR fixes:

N/A

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)