Our cacheability debug headers show completely wrong information

Step 1: Let's introduce new headers and leave the old ones untouched.

The only major difference here is that we now affect cacheability in DPCS by folding contexts for all responses, not just the ones that came from the renderer.

After we fix failures caused by this, we can go to step 2: Move all usages of X-Drupal-Cache-Contexts to X-Drupal-Dynamic-Cache-Contexts and see how many failures we get. Then we can fix those by allowing them to use the old header and create follow-ups to evaluate why they were failing and fix them.

Which is why I think we need to move the headers to the actual caches. It makes no sense for FinishResponseSubscriber to set headers because said subscriber does not handle caching and doesn't know how the caches use the cacheability. If we move them to DPC and PC respectively, then we can make sure the headers actually reflect what is happening in the cache.

If you then want to replace page cache to respect contexts, you could output your own headers if you choose.

The fact that they're used for debugging only is nice, but if an upgrade of RenderCache causes the info to actually be correct and said change causes a lot of test failures because our tests relied on the wrong info, then what's the point? Tests checking for both user and user.permissions completely beats the purpose of testing as it's an unrealistic scenario to begin with.

Test will fail massively, something extra slipped into the patch -.-

Okay so this surfaced a few tests that fail when cache context folding does affect tags. Now, I've been giving it some though and internal cache mechanisms should never affect what you're caching, as demonstrated by these test fails. This is also reflected in the other issue's changes to RenderCache, which did alter the very thing it was caching.

Only DPC affects tags/contexts when setting the actual item in its cache. That does not mean that PC wants to work with these altered cache tags. It simply doesn't care. As proven by the need for AnonymousUserResponseSubscriber to exist. This also means the page cache debug headers should not optimize contexts as that's not what happens in its cache.

So attached is a patch that still outputs the new headers, but does not affect the response whatsoever. This should go completely green.
I'll also attach a patch that moves the page cache headers to page cache and makes sure page cache doesn't affect the response's cacheability either.

Once we have those 2 sets of headers in the right place, I can update X-Drupal-Cache-Contexts to not optimize its tokens as it provides false information to the tests/debugger. I expect tests to fail there, which we can then update.

This moves the page cache debug headers to page cache so we now have debug headers for MISS/HIT, tags and contexts in both page cache and dynamic page cache. It should go green as it still applies to all responses the same way, but I might have missed something.

This patch shows that page cache debug headers were still sent even if a request policy decided that caching should be denied:

if ($type === static::MASTER_REQUEST && $this->requestPolicy->check($request) === RequestPolicyInterface::ALLOW) {

If this line failed because of a request policy, FinishResponseSubscriber would still kick in and output the headers because FRS only cared about being on the master request and dealing with a CacheableResponseInterface respone.

I'm interested to find out how many tests would break if we only sent debug headers when the above check passed.

Now that #7 went green, let's put our money where our mouth is. Let's make sure the "should we cache this" check uses the same contexts we actually output in the header. This should be interesting.