Investigate other solutions to the performance problem caused by the group templates counter

Follow-up from #438146 (closed)

I think I've exhausted any reasonable further attempts to improve the query performance in this area, so now I have the following suggestions/ideas:

1. Do some caching. However as this is very user-specific and the page isn't visited very often, probably not very useful. It would be possible to implement some form of permissions cache, but the problem is likely the same elsewhere in this repo - most changes haven't been made with caching in mind and so the cache could end up stale, which isn't ideal.
2. Make the counter less accurate. My thinking here is to limit the max number it can hit, say "99", then just turn it into "99+". Won't completely solve the issue but will prevent it hitting the very worst times
3. Just remove the counters from those tabs 🤷 I find pretty much all of these counters useless (e.g. this repo's issues count is 64.4k right now - what do I do with that info? 🙈). We could either grey-out the empty tabs, add a simple "yes there's stuff here indicator", or just not replace it at all. It doesn't seem like it's worth the performance hit.

Proposal

Re-evaluate the solution and explore alternatives for Group project template cannot be seen by inheri... (#295646 - closed).

Maybe we shouldn't pick all available groups for user (see problem) but add an additional constraint.

As an option, require the user to have a direct membership in the root group in order to see group's templates defined in subgroups. That should prevent user from seeing unrelated public/internal templates and should also improve the performance of the query.

/cc @vyaklushin @jpcyiza @sean_carroll