Update RendererInterface::addDependency() to accept *any* object, not only CachableDependencyInterface objects

Extracted from #2099137-133: Entity/field access and node grants not taken into account with core cache contexts.

+++ b/core/lib/Drupal/Core/Render/BubbleableMetadata.php
@@ -109,18 +109,26 @@ public static function createFromRenderArray(array $build) {
+    // Objects that don't implement CacheableDependencyInterface must be assumed
+    // to be uncacheable, so set max-age 0.
     $meta = new static();
...
+    $meta->maxAge = 0;

This is problematic, because it doesn't apply to everything.

E.g.:

1. in the issue that spawned this issue (#2099137), we need this behavior for AccessResultInterface objects that aren't cacheable.
2. but e.g. in EntityFormDisplay, we are currently still doing this:
   

           $field_definition = $this->getFieldDefinition($name);
           if ($field_definition instanceof CacheableDependencyInterface) {
             $this->renderer->addDependency($form[$name], $field_definition);
           }
   

   We could remove that if-statement too, but then we'd effectively be setting max-age = 0 on this form, which doesn't make sense. Because in this case, we have e.g. BaseFieldDefinition, which is a never-changing object. Which means max-age = 0 is absolutely not what we want: the form should still remain cacheable!

The difference between the two examples is that the access result is dynamically calculated (and is therefore not cacheable without it providing cacheability metadata, i.e. without implementing CacheableDependencyInterface). But the field definition is hardcoded, and is thus permanently cacheable.

The question is: how do we fix this? The simplest possible solution is to special case AccessResultInterface to get max-age = 0. The architecturally more sound choice would be to add a DynamicallyCalculatedInterface or UncacheableByDefaultInterface and let AccessResultInterface extend that. But that seems like a whole can of worms.

Any ideas?

( btw. funny side effect: I thought of _exactly_ that scenario when reading the IS, then saw that you had the same thought and my solution was the same as above.)

Hah! :)

Will do that, then.

Interesting. In #2, I only looked at it from one angle. #5 basically presents the inverse angle. #5 basically says that we should set max-age = 0 if CacheableDependencyInterface isn't implemented. And it says BaseFieldDefinition should simply implement CacheableDependencyInterface. Which makes a lot of sense.

The implication of #5 is: if your page/render array is uncacheable because of a dependency on an uncacheable object that actually is cacheable, then make that object implement CacheableDependencyInterface.

It's hard to argue with that, since it just means that all things that can implement CacheableDependencyInterface should.

I think "permanent" doesn't capture as many semantics as "unchanging". "permanent" clearly alludes to max-age, but "unchanging" also points out that there are no invalidations (no cache tags) and no variations (no cache contexts), and that it can thus be permanently cached (max-age == permanent).

#10: exactly!

+++ b/core/lib/Drupal/Core/Cache/UnchangingCacheableDependencyTrait.php
@@ -0,0 +1,38 @@
+trait UnchangingCacheableDependencyTrait {
+
+  /**
+   * {@inheritdoc}
+   */
+  public function getCacheContexts() {
+    return [];
+  }
+
+  /**
+   * {@inheritdoc}
+   */
+  public function getCacheTags() {
+    return [];
+  }
+
+  /**
+   * {@inheritdoc}
+   */
+  public function getCacheMaxAge() {
+    return Cache::PERMANENT;
+  }
+
+}

There is nothing to test. This is just a trait to implement 3 interface methods declaratively, with zero logic.

See #8 and #10 for why this name was chosen. The return values match the semantics of the word "unchanging".

#12 pointed out that we're modifying BaseFieldDefinition, but not properly explaining why.

• #2463029: EntityFormDisplay should update $form with cache tags of FieldConfig, FieldStorageConfig, EntityFormDisplay config entities had to check if the field definition & field storage definition implement CacheableDependencyInterface, because you can only call RendererInterface::addDependency with objects that implement that interface. The goal of this issue is to remove that requirement: any object can be passed, but objects that don't implement that interface are automatically considered uncacheable.
• To that I remarked in #2.2 that it's not quite correct, because e.g. BaseFieldDefinition doesn't implement CacheableDependencyInterface yet is still cacheable. To which #5 said, and what this patch does: let's make that then implement that interface! And add a trait at the same time, because many things in Drupal are defined in code like that and therefore have unchanging cacheability.

Clearly, these are simply separate problems! I'm moving the trait and the changes to BaseFieldDefinition into its own issue. Did that: #2467627: Field(Storage)DefinitionInterface should implement CacheableDependencyInterface.

Re-uploading this patch without the trait and without the changes to BaseFieldDefinition, restoring to RTBC state.

Yay! This unblocked, now rerolled without this patch included: #2099137-157: Entity/field access and node grants not taken into account with core cache contexts.

Also updated the CR at https://www.drupal.org/node/2460819.

Oh, it also unblocked #2467627: Field(Storage)DefinitionInterface should implement CacheableDependencyInterface.