Views Rendered Entity field adding unneeded entity display cache tags

Here's a patch where getCacheTags() returns an empty array to see how it does against tests.

I discovered that the entity render array does not have the entity view display config as a cache tag that bubbles up, unless the Layout Builder module is enabled. In that case, next step will be to amend the patch to include cache tags for the selected view mode. Update patch and tests hopefully soon.

Rebased MR against 11.x and tweaked some comment language.

@catch I vaguely recall having a similar thought when I originally ran into this three years ago, and then discovering that the tags still needed to be identified in the plugin getCacheTags() code. If so, I don't remember why, so I'll have to look into it again and refresh my memory.

ETA. Never mind, the strikeout text in the IS talks about this. And my comment #4 says that those display cache tags aren't bubbling up? I will re-confirm.

I investigated some and found a couple things.

First, I installed Drupal with standard profile against latest 11.x-dev (#840a726). Then I set http.response.debug_cacheability_headers: true. I created and saved an article node, and viewed the cache tags in the page response, which are these:
block_view config:block.block.olivero_account_menu config:block.block.olivero_breadcrumbs config:block.block.olivero_content config:block.block.olivero_help config:block.block.olivero_main_menu config:block.block.olivero_messages config:block.block.olivero_page_title config:block.block.olivero_powered config:block.block.olivero_primary_admin_actions config:block.block.olivero_primary_local_tasks config:block.block.olivero_search_form_narrow config:block.block.olivero_search_form_wide config:block.block.olivero_secondary_local_tasks config:block.block.olivero_site_branding config:block.block.olivero_syndicate config:block_list config:search.settings config:system.menu.account config:system.menu.main config:system.site config:user.role.anonymous http_response local_task node:1 node_view rendered user:1. The cache tag for the entity view display is not included.

Next, I installed Layout Builder, but did not configure any entity view displays to use it. Reloading the article node, the cache tags are these: block_view config:block.block.olivero_account_menu config:block.block.olivero_breadcrumbs config:block.block.olivero_content config:block.block.olivero_help config:block.block.olivero_main_menu config:block.block.olivero_messages config:block.block.olivero_page_title config:block.block.olivero_powered config:block.block.olivero_primary_admin_actions config:block.block.olivero_primary_local_tasks config:block.block.olivero_search_form_narrow config:block.block.olivero_search_form_wide config:block.block.olivero_secondary_local_tasks config:block.block.olivero_site_branding config:block.block.olivero_syndicate config:block_list config:core.entity_view_display.node.article.default config:search.settings config:system.menu.account config:system.menu.main config:system.site config:user.role.anonymous http_response local_task node:1 node_view rendered user:1. The entity view display tag now is included.

Doing a little debugging, from what I can tell, the isApplicable() method in Drupal\layout_builder\Plugin\SectionStorage\OverridesSectionStorage and Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage is adding the entity view display as cacheable dependency. Otherwise without Layout Builder enabled, the entity render array does not bubble any entity view display cache tags. Should there be an issue to add the entity view display as a cacheable dependency in \Drupal\Core\Entity\EntityViewBuilder::getBuildDefaults() or similar?

On the Views side, I noticed this in the docblock for Drupal\views\Entity\View::addCacheMetadata():

Cache metadata is set per view and per display, and ends up being stored in
   * the view's configuration. This allows Views to determine very efficiently:
   * - the max-age
   * - the cache contexts
   * - the cache tags
   *
   * In other words: this allows us to do the (expensive) work of initializing
   * Views plugins and handlers to determine their effect on the cacheability of
   * a view at save time rather than at runtime.

So, even if the entity render array does bubble the view display cache tags, it might still make sense to compute them in RenderedEntity::getCacheTags() so they get saved to the view config.

After some digging:
In Drupal\Core\Entity\Entity\EntityViewDisplay::postSave(), the entity view builder resets its cache, which means it invalidates everything tagged with {ENTITY_TYPE_ID}_view, where {ENTITY_TYPE_ID} is the ID of the entity type the view display is for. (So saving a entity view display for a node type will invalidate cached items tagged with node_view). In this case, is it necessary to even include entity view display cache tags at all? The {ENTITY_TYPE_ID}_view tag does get bubbled, so to the original raised question, it doesn't seem necessary for the Rendered Entity plugin at least to include any entity view display cache tags.

Should there be an issue to add the entity view display as a cacheable dependency in \Drupal\Core\Entity\EntityViewBuilder::getBuildDefaults() or similar?

Something like that sounds good to me yes.

This does raise a separate question: is invalidating {ENTITY_TYPE_ID}_view too broad on an entity view display save? If we do add tags for entity view displays to entity render arrays, should it be enough for the view display tags be invalidated and not invalidate {ENTITY_TYPE_ID}_view? Not sure of the ramifications for what seems to be a pretty significant change.

In any event, moving this back to needs work to update MR and Issue to reflect solution of not including display cache tags via the plugin.

Updated MR to so that the RenderedEntity plugin returns empty array for getCacheTags() and rebased.

Updated IS to reflect new solution.

Per conversation with catch on Slack, because the ENTITY_TYPE_view cache tags are invalidated on entity view display save (see #24), there is no need to invalidate the individual cache tag for the display itself.

Created follow-up issue for the docblock in Drupal\views\Entity\View::addCacheMetadata(): https://www.drupal.org/project/drupal/issues/3409816

Moving this back to RTBC.

Added post update hook with tests to update existing view configurations to remove rendered entity cache tags.

Made changes per review question and rebased.

Rebased for merge conflict.