Move more PHPStan global ignore patterns to baseline

We should also discuss these:

    - "#^Plugin definitions cannot be altered.#"
    - "#^Missing cache backend declaration for performance.#"
    - "#cache tag might be unclear and does not contain the cache key in it.#"

These are rules in phpstan-drupal I added to help with common code review problems in plugin managers. We could see about removing them from default config or improving them. Like maybe the cache tag thing is a nit and unneeded

Would we need some sort of plan to make sure we can get rid of those 1300+ added errors. My main worry here would be we add those, it takes a huge amount of time to fix them, and blocks us from going up to even level 1 (which adds another 1000 items). In theory a 1000+ items baseline is no problem, except it's more difficult to easily spot patterns on what to fix first.

Are there parts here which we can easily fix now, which can reduce a lot of problems. (for the current baseline the deprecated REQUEST TIME is 60% of it for example).

As you mentioned one of the reasons to do this was stop the bleeding of #3260785: [meta] Fix return.missing PHPStan L0 errors. But instead of only committing (and thus enabling that rule) when all items are fixed, we might commit that with the low hanging fruit fixed, and the rule enable, and still add half of the items to the baseline (everything which is not the same simple one line adjustment).

Offcourse those changes are more difficult in Drupal due to BC, thanks for reminding this.
One other thing to note when having a large baseline, is that this might introduce more conflicts in the baseline file when multiple patches are pending. Although this might only be an issue on real phpstan cleanup issues, not that much in other patches.

I do fully agree otherwise here, and patch looks good.

Hm... we seem to have a different approach to this. I was in the process of doing the exact opposite of the changes in the patch. Bundling up the generic rules so they could be linked to an task issue for addressing them.

Your point is well made about catching changes but the wall enormous wall of items in the baseline doesn't provide a way organize efforts around fixing them and make it very difficult to review the fixable outliers.

This needs a reroll because of new things introduced since it was last run - plus #3274016: Remove \Drupal\Core\Test\AssertMailTrait::verboseEmail() from Drupal 10 has landed so the baseline will be a bit smaller.

I think we should proceed here - this will prevent us from making more mistakes like removing TestBase::verbose() but leaving a usage in.

Committed 57a7de3 and pushed to 10.0.x. Thanks!

Wait, where was the review on this? Self RTBC and commit? I still think this is the wrong approach.

I'll just open a new issue with what I think is the correct approach.

I see 2 pages of changes between and the last RTBC without any reviews other then my objection to the approach which was never addressed. Maybe the merge requests are just handled a bit different but it felt like a self RTBC to me.

@neclimdul Can you link the followup issue here?