Fix pipeline on Drupal core 11.3

I made a small change so that it is using version_compare() instead of float comparison. This matches other similar code in the module. I think there should be a comment explaining why the code is different starting in Drupal 11.3.

The previous-version tests are passing, so I think this can be merged once the comment I refer to in #5 has been added.

So does the ::setCacheKey() call happen automatically in ::onKernelController() in 11.3?

That could be put into the comment. Anytime I see different code paths for different versions, I wonder why it is.

I think I'd prefer an inline @phpstan-ignore-next line comment over the baseline. That will be easier to adjust once we require 11.3 and remove that call.

Not sure a version check is needed at all, I explicitly requested for that deprecation to be D13, but if we have to touch it anyway thanks to phpstan then we can add it, I prefer compare_version() too. And it avoids the runtime deprecation. As for a comment, no strong feelings, we could slightly adjust the existing one, but it doesn't really matter for this call _why_ it's deprecated. The actual reasons are fairly complex, it's not just because of fibers, it's more that render caching removed much of it's usefulness ages ago as it heavily depends on render cache hit rates how many aliases are needed on a given page and it either loads too much or not enough. But there's no reason to write half a book on that in this module.

I don't think there needs to be half a book. But consider this:

if (version_compare(\Drupal::VERSION, '11.3', '<')) {
  do_the_thing();
}
else {
  \Drupal::service('thing_service')->doTheThing();
}

It's clear what happened here: A procedural function was replaced by a service; no comment needed. But in the merge request, there is no else; the code has no replacement and, for me, that calls for some sort of explanation.

not against next testing in the MR, the project has a weekly next testing, that was my attempt at dealing with this. The problem is that as long as next branches are not set to fail, I don't get notifications (plus, I tend to get a ton of notifications, for example with the recent previous minor composer issues).

I think what I'd prefer is having next minor set to fail and not just warn so I get e-mails if it starts to break and have them on merge request as a manual job. I haven't verified if that's easily possibly yet. I also had this vague idea of building a dashboard of all my contrib projects and their CI status, specifically on next.

> If phpunit next minor fails - you'd get an email. no?

No because next minor is allowed to fail, so it's just a warning and that doesn't send a mail. We'd need to flip the allow_failure flag: https://git.drupalcode.org/project/gitlab_templates/-/blob/main/includes...

But then I wouldn't want to run it on merge requests as that would result in exactly the problem we have right now, it interferes with merge requests.

Thanks.