Problem/Motivation
Drupal sites typically have a lot of blocks and block cache tags (umami frontpage has about 20). They usually rarely change and if you change the block overview, we often change
At the same time, if you have multiple themes, changing blocks from one theme wont' change the others, so the global list cache tag doesn't need to be invalidated.
Strangely, there's also a a Block::postSave() that invalidates the block configs cache tag on saving a new one, explaining that it contains the theme, but as far as I see, that's not actually the case, leftover?
The performance impact of this isn't huge. In the umami example, this results in about 20 fewer cache tags in the http header/page cache, but we only save very few queries as block render caches often come with additional unique cache tags (views, block_content:id, menus, ..). But each tag in an IN () condition also costs a tiny bit I suppose.
I also removed the block_view cache tag, I can't think of a scenario where that is needed. I think that was pretty much the first cache tag we ever added, before we had list and per entity cache tags. We could also look into removing those entirely, or alternatively, use them for view displays, because I see another 10 cache tags for view displays (block_content, media and node), we could drop those in favor of the _view cache tag.
Last, the global list cache tag for blocks is still there but not actually invalidated, we should either remove it or add it back.
This will fail a lot of cache tests that expect those tags but hopefully not much else.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet