fix: static files served with different vary headers

[pauldambra]

when using internal-t posthog route (which i think is just PostHog and managed reverse proxy)

going backwards and forwards between us.posthog.com and posthog.com I get a CORS error

I believe that because

• we're sending vary: accept-encoding
• the browser is caching the static file on one domain,
• then re-using it on the next
• _and reusing the header access-control-allow-origin: https://posthog.com
• the browser re-uses the cached response and headers which makes it invalid

the default headers from whitenoise are https://github.com/evansd/whitenoise/blob/b3d250fd17da0e280d58b6dc4935c4573ebe8b55/src/whitenoise/responders.py#L170 vary: accept-encoding so it's probably whitenoise adding the vary headers for us (i guess it could be contour or envoy but that feels like it's whitenoise)

NB the real fix here IMO is to send access-control-allow-origin: * but the CorsPostCsrfMiddleware middleware that I think would add the domain specific access-control-allow-origin header in django shouldn't run on these static file requests

I don't think it is since it would add the vary: origin header, so I think the access-control-allow-origin is being added somewhere else in the stack

I don't know where in the stack, so for the time being we can try and add the vary by origin header. this means folk will download the assets more often than they strictly need to but that's better than current

I haven't tested this since whitenoise doesn't serve static assets in DEBUG