Add a CacheTagsAggregator to reduce DB cache tags while keeping API cache tags fine-grained

needs to fix CS

I don't really understand the goal of this. Some real use cases of when you'd want to use this could help,

The example is technically valid, but it's not something you ever want to do. Ending up with too many node:list cache tags on your site is one of the main performance issues.

Invalidation and checking also doesn't follow the same rules. Going with the example, When invalidating, we typically invalidate node:ID, node:list, node:list_article and possibly more. And we must invalidate all of them. When checking for invalidation, I could imagine a case where we say if an item has node:list and node:ID then we can ignore node:ID, but with the bundle cache tags, that gets complicated/expensive again.

Maybe a scenario where you have 10 global config cache tags that all add some stuff to global attachments (like google analytics and others), those you could aggregate to a single one, but that will be very site specific and you'd need to hardcode that, because any sort of configuration for that will most likely be more expensive to check than an extra query or even just a more entries in an IN condition.

I think this could be useful for headers, but we'd probably want to use a de-duplication strategy similar to how cache contexts work, not always replace.

There are various issues around like #2844620: Automatically split cache debug headers into multiple lines when they exceed 8k and #2952277: Minify the cache tags sent in the header and related issues trying to deal with this.

We have similar logic in CacheContexts::optimizeTokens() - when a cache object has both user.permissions and user cache contexts, it will change this to only user because user.permissions is implied.

With cache tags, if we have node:1, node:123 and node:list, we can optimize that down to just node:list in the headers. When entities are saved, the list cache tags are invalidated, so we know the CDN will get the invalidation every time.

Then when the response doesn't have node:list there are two choices - optimize it down anyway to reduce the header size (and potentially serve the HTML faster), or skip the optimization and have overly aggressive cache invalidation at the CDN level.

Since core doesn't serve these headers by default, and because the debug cache headers need to be correct, this wouldn't really be usable in core itself, but given the number of modules that are trying to do similar things, it should probably either be in core or a shared dependency module they all use.

@geek-merlin, since Drupal 11.3 the number of cache tag lookups on most pages has approximately halved or less. e.g. #3505248: Ability to preload frequently used cache tags, #1237636: Lazy load multiple entities at a time using fibers and several other issues. More details on https://www.youtube.com/watch?v=qgmGtKJClRM and in https://www.md-systems.ch/en/blog/2025-12-16/performance-improvements-dr.... So a lot of the previous trade-offs between fine grained cache tags vs. lookups are becoming moot as regards cache backend performance.

You haven't replied to #8, I still don't really understand how you imagine specific use cases and how this would help. I tried to explain why just aggregating everything node:* to node_list is very much not what you want, as saving any node would then always invalidate every single rendered node (I get it's just an example, but it's not a good one). Maybe you could get rid of a handful of more specific cache tags, but especially with redis 2.x, which consistently uses a pipeline now for multiple invalidations, there's minimal difference between invalidating 1 and 5 cache tags at once now. The database backend still uses one query per tag, but you probably shouldn't use database if you care about performance and even then, invalidations aren't really the main concern, there's already static caching to not invalidate tags more than once per request.

The global cache tag use case I mentioned there is solved by https://www.drupal.org/node/3505248, tags that are used on most/many pages can be put into that list and then they're prefetched on every page in a single SELECT/mget. It's not automatic apart from the one that core ships with by default, but if you care, it's easy to opt into that, at least as easy as writing such an aggregator.

Another example is block cache tags, those are very repetitive and long, but I think it's better to get rid of them at the source which I'm trying in #3341042: Use only the list cache tag for block config entities but there are a few edge cases that something like this would run into as well.

Correctly used, specific cache tags are a good thing and valuable, but it's something that needs to be thought about and a tradeoff to be found. As mentioned, invalidations are relatively cheap, and either a cache tag is actively used, then it generally shouldn't be aggregated, or not, and then it's existence in the database is an absolutely tiny cost.

Re #9, what I once did a very long time ago in our now defunct news distribution is a custom implementation that used a combination of hardcoded rules and very short hashes to compress cache tags, so node:1 became n:1, and config:block.block.some_long_block_id became something like c:b:abc. That cut down significantly on the header size and mostly solved the issue for us. That was before purge and related projects existed.