make CORS opt-in per backend now that user_router replaces credentials

[crandles]

trickster currently sets Access-Control-Allow-Origin: * on every response unconditionally in pkg/proxy/headers/forwarding.go AddResponseHeaders (line 336). that was defensible when caches only held public read-only telemetry, but the new user_router credential-replacement path (pkg/backends/alb/mech/ur/user_router.go) lets cached responses carry privileged upstream data, so any browser origin can issue credentialed GETs and read the body.

CORS should be opt-in per backend/path, or scoped to a configured allowlist, rather than wildcard-on-by-default.

[jranson]

we will need to be careful with the implementation here. Since Trickster is a reverse proxy, we can't just accept+proxy any origin's remotely-provided CORS headers, since a permitted origin may not (and should not) have awareness of the subdomains used by any reverse proxies (e.g., Trickster instances) between the caller and the origin. For example, if we preserved the origin's headers which send Access-Control-Allow-Origin: https://api.internal.example.com, the browser CORS check would fail if the Trickster domain is trickster.example.com. That is why the * is used by default. So we'd need to provide an easy way for operators, on a per-backend-basis, to either opt to preserve all of the origin's CORS headers unaltered, preserve the origin's headers while overriding specific ones (e.g., replace the domain in the Access-Control-Allow-Origin header) or otherwise overwrite all CORS headers (either with our existing permissive * or a custom collection).

[houyuwushang]

@jranson I traced the response paths and think this can use one policy consistently for proxied, OPC, and DPC responses. Would this config shape match what you had in mind?

cors:
  mode: merge # preserve, merge, or replace
  headers:
    Access-Control-Allow-Origin: https://trickster.example.com

preserve would leave the origin's Access-Control-* headers alone, merge would preserve them and apply the configured overrides, and replace would remove them all before applying the configured map. An empty map in replace mode would disable CORS. A path-level block could override the backend-level policy.

There are two compatibility choices I don't want to guess at: should an omitted cors block retain today's * behavior for 2.x, and for an ALB/user_router should the client-facing backend's policy win over the selected member's policy? My inclination is yes to both. preserve and merge would also vary cache keys by the request Origin so an origin-specific response header is not replayed to another origin.