Add HookDependsOnModule to all help hooks

Applied the MR and all help hooks appear to be updated. Very neat feature.

I plan to run some checks on the impact of this, I want to have an understanding of the impact of this and how it actually benefits us in practice before RTBC.

Testing with core umami, with help module uninstalled:

HEAD:
container cache length: 526985
hook_list length: 46700

MR:
cache container length: 525295
hook_list length: 43724

that means the container cache size reduction is just 0.2%, which makes sense as this only impacts the container if this allows us to skip the service for it completely, we'd need to move the help hooks to their own services for this to have a benefit for the container.

hook_list is better, that's an improvement of around 6%, but it will be much smaller on sites with lots of contrib projects, it will be the same reduction of 3k (or less if they use fewer core modules) and for my distrubtion, hook_list is 100k, so twice as large already.

So, unsure if this is worth it.

I'm also wondering if this is worth it. What makes hook_help special? In theory we should do the same for all hooks where the provider of the hook is not a dependency of the module implementing the hook.

If it is indeed worthwhile, it seems like this could be automated somehow, e.g. with a registry of hooks and what modules they belong to.

Help is special in that it is by far the most common hook that almost all modules implement in core and contrib.

We have no information on who calls a hook, even for help, it is possible that someone else calls it, such as a help2 module in contrib.

So yes, this might be a won't fix as the gains might not outweigh the complexity and risks.

We have some ideas around caching to use some sort of cache collector, so if nobody ever calls hook help, it won't end up in the active cache. But the cost of that is slower cache warmup, stampedes and so on.

Would it be good at class level instead? Like if all the hooks are views related on the class say HookDependsOnModule('views')

You can do that, but the performance gains are tiny for a single class too. The main reason for adding this for me wasn't performance but DX.

https://git.drupalcode.org/project/drupal/-/commit/3e6179a621d37ce18d1da... is a good example (FileViewsHooks). That actually is a views hooks class, if you have optional hooks for a given module, you might also depend on services from that module, with this change, you can actually require the parameter no because the service will only be registered if the module is there.