VariationCache needs to be more defensive about cache context manipulation to avoid broken redirects [#3452181]

Problem/Motivation

If people get a render array or cacheable code flow where they can add to a parent and in their child specify cache contexts, those will accumulate and VariationCache will work by virtue of cache redirects.

However, I've recently seen core code where parent cache contexts were left out and/or manually optimized and by happy accident this hasn't caused any issues yet, but if a longstanding bugfix (#2973356: Cacheability information from route access checker access results are ignored by dynamic_page_cache) gets in we might all of a sudden see bug reports and perhaps even security issues.

We should make VariationCache more defensive by checking for all previously set cache contexts every step of a redirect chain. If one is missing, we should immediately throw an exception and bail out. This should catch a lot of insecurely written code that doesn't properly set the right cache contexts by letting people know there is something wrong with their code.

Steps to reproduce

Try the following render array:

// This is the starting point.
$build['parent'] = [
  '#markup' => $user->hasPermission('foo') ? 'You can foo!' : 'You cannot foo',
  '#cache' => ['contexts' => ['user.permissions']],
];

// This is in a place where the original build can be altered.
if ($user->hasPermission('foo')) {
  $build['parent']['child']['#cache']['contexts'] = ['user'];
  $build['parent']['child']['#markup'] = $user->id() === 13 ? 'You are 13!' : 'You are not 13';
}

This is a horrible example, but it works fine. Now imagine if in that alter step they tried to be clever and said: "Oh hey, user and user.permissions fold into user, so let's do that here already".

if ($user->hasPermission('foo')) {
  // Trying to be smart here by optimizing parent.
  $build['parent']['#cache']['contexts'] = ['user'];
  $build['parent']['child']['#markup'] = $user->id() === 13 ? 'You are 13!' : 'You are not 13';
}

The above would cause a redirect to be written for 'user' a user with permission 'foo' came first and for 'user.permissions' if anyone else came first. Whereas the actual redirects should be: user.permissions for everyone + an extra redirect beyond the original one to user for users who have the 'foo' permission.

VariationCache would choke here because it tries to heal ['user'] vs ['user.permissions'] but they have nothing in common. ['user'] and ['user', 'user.permissions'] does and would properly apply self-healing and create the second redirect.

A more practical example can be found in UserAccessControlHandler::checkAccess() for the view operation. I have yet to file a bug report for that, but it applies the flawed logic above where it doesn't always add the user.permissions cache context even though it should.

        if ($account->hasPermission('access user profiles') && $entity->isActive()) {
          return AccessResult::allowed()->cachePerPermissions()->addCacheableDependency($entity);
        }
// AT THIS POINT EVERYTHING SHOULD VARY BY USER.PERMISSIONS, YET DOESN'T.
        // Users can view own profiles at all times.
        elseif ($account->id() == $entity->id()) {
          return AccessResult::allowed()->cachePerUser();
        }
// AT THIS POINT EVERYTHING SHOULD ALSO VARY BY USER, YET DOESN'T.
        else {
          return AccessResultNeutral::neutral("The 'access user profiles' permission is required and the user must be active.")->cachePerPermissions()->addCacheableDependency($entity);
        }

As explained in the issue where I found this, this could lead to a person with the same permissions as the profile owner to lock the owner out of their profile if said non-owner came first and got an access denied which then gets cached per permissions. If this access check were to trigger for the owner first and then for a non-owner, we'd get the broken redirects described above.

Proposed resolution

Add a sanity check to VariationCache to enforce that any previous cache contexts up until the point where we want to store something are present. This point can be right after the initial get, but equally after a few redirects. That entire chain must be represented by any subsequent CacheRedirect that is being stored.