CDN module 4.x: no new features + drop BC layers + drop now irrelevant headers + PHP >=8.1 + Drupal >=9.4

This patch already implements all the certainties. What's left is bumping the PHP version requirement plus taking advantage of that version bump.

TODO: investigate #3061110-12: Automatically prevent CKEditor from loading from the CDN when far future functionality is enabled.

So far, this doesn't buy us much. I think it's probably worth waiting for #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it to land.

If we make the 4.x version require Drupal >=9.0, then we can also increase the PHP version requirement to PHP 7.2 and probably even 7.3. See #3079791: Bump Drupal's minimum PHP version to 7.2 as soon as 9.0.x is branched (a higher version may be required later). That would allow us to go further than #3100598: CDN module requires Drupal >=8.8.0 ⇒ take advantage of PHP features introduced in 5.6 and 7.0 .

I'm thinking it should

1. require Drupal 9.3 for autowiring
2. PHP 8 since Drupal 10 will require it and active support for PHP 7.4 will end at the end of 2021. (Version 3 of the CDN module will have been around for 5 years, I'd rather make version 4 be supportable for the next 5 years.)

#2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it landed!

New:

1. #3228162: Fix Drupal 9-only deprecation notices while retaining Drupal 8 compatibility added a BC layer to remain compatible with Drupal 8 while fixing Drupal 10 deprecations.
2. #3216302: Remove Tour support

New:

1. #3194164: Harden against invalid calls to file_create_url(): avoid TypeError in CDN module's code execution added a warning that is obsolete once sites are on Drupal 9.3, because core will be just as strict as the CDN module. We should remove that gracefully warning logging.

Rebased #2.

Rebased incorrectly.

Generated patch incorrectly… This is what I should've uploaded in #13.

Remove the BC layers added in #3228162: Fix Drupal 9-only deprecation notices while retaining Drupal 8 compatibility and #3194164: Harden against invalid calls to file_create_url(): avoid TypeError in CDN module's code execution.

😬 Again wrong patch. Clearly I'm used to the merge request workflow at this point…

+++ b/cdn.routing.yml
@@ -1,17 +1,7 @@
-# The /cdn/farfuture route has been deprecated and is rewritten
-# in CdnFarfuturePathProcessor.
 cdn.farfuture.download:
-  path: '/cdn/farfuture/{security_token}/{mtime}'
-  defaults:
-    _controller: cdn.controller.farfuture:download
-    _disable_route_normalizer: TRUE
-  requirements:
-    _access: 'TRUE'
-    mtime: \d+

With this disappearing, #2870435-21: Support additional stream wrappers is relevant again. Just to be safe, we should clear all caches when updating. That still won't fix edge caches or reverse proxies, but hopefully 99% of sites will have been on the latest Drupal 8 release for a long time before upgrading. They've already had the chance to do so for over 2 years at this point, because https://www.drupal.org/project/cdn/releases/8.x-3.3 is the first release to include #2870435: Support additional stream wrappers.

However esoteric/edge case-y that may be, taking advantage of #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it will require a container rebuild anyway. So … let's do so.

Did

Evidently we can also remove the 8.x-3.x hook_update_N() update hooks plus the associated tests.

So … I tried using autowiring, but failed miserably:

Error: Class 'Symfony\Component\Config\Resource\ClassExistenceResource' not found in Symfony\Component\DependencyInjection\Compiler\AutowirePass->createTypeNotFoundMessage() (line 397 of /Users/wim.leers/Work/d8/vendor/symfony/dependency-injection/Compiler/AutowirePass.php).
Symfony\Component\DependencyInjection\Compiler\AutowirePass->createTypeNotFoundMessage(Object, 'argument "$config_factory" of method "Drupal\cdn\CdnSettings::__construct()"', 'cdn.settings') (Line: 388)
Symfony\Component\DependencyInjection\Compiler\AutowirePass->Symfony\Component\DependencyInjection\Compiler\{closure}() (Line: 926)
Symfony\Component\DependencyInjection\Definition->getErrors() (Line: 51)
Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Object, 1) (Line: 82)
Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->processValue(Array, 1) (Line: 32)
Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Array, 1) (Line: 46)
Symfony\Component\DependencyInjection\Compiler\AbstractRecursivePass->process(Object) (Line: 94)
Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object) (Line: 762)
Symfony\Component\DependencyInjection\ContainerBuilder->compile() (Line: 1295)
Drupal\Core\DrupalKernel->compileContainer() (Line: 900)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 472)
Drupal\Core\DrupalKernel->boot() (Line: 707)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I figured that the CDN module's service specifying the type ConfigFactoryInterface makes it impossible for the autowiring to reliably figure out the concrete class.

But turns out it's worse. The service ID needs to match the class name. This is … not very useful then. This is also why Drupal core is not yet using it: #3049525: Enable service autowiring by adding interface aliases to core service definitions.

Fortunately, this is the case for at least the cdn.settings service: its FQCN is \Drupal\cdn\CdnSettings. But alas:

The website encountered an unexpected error. Please try again later.
Symfony\Component\DependencyInjection\Exception\RuntimeException: Cannot autowire service "cdn.html_response_subscriber": argument "$cdn_settings" of method "Drupal\cdn\EventSubscriber\HtmlResponseSubscriber::__construct()" references class "Drupal\cdn\CdnSettings" but no such service exists. You should maybe alias this class to the existing "cdn.settings" service. in Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue() (line 54 of /Users/wim.leers/Work/d8/vendor/symfony/dependency-injection/Compiler/DefinitionErrorExceptionPass.php).
Symfony\Component\DependencyInjection\Compiler\DefinitionErrorExceptionPass->processValue(Object, 1) (Line: 82)
…
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

So … in the end … I was able to autowire a single service: the only service that depends only on CDN module-provided services… because until #3049525: Enable service autowiring by adding interface aliases to core service definitions, this will work for almost no service relying on core services!

This makes the CDN module as ready for autowiring as it possibly can be — i.e. it makes the CDN module forward-looking.

Since the CDN module's services never were an API, it's fine for me to rename them without notice. Especially when doing a new major release.

Now let's finally take advantage of #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it!

This is the minimum set of changes. There are probably refactoring opportunities now, but not yet taking action on those.

Fix PHPCS violations.

+++ b/cdn.module
@@ -74,7 +74,7 @@ function cdn_editor_js_settings_alter(array &$settings) {
-  if (!\Drupal::service('cdn.settings')->farfutureIsEnabled()) {
+  if (!\Drupal::service('Drupal\cdn\CdnSettings')->farfutureIsEnabled()) {

#21 made this change.

(As well as a few others like this, but those have been refactored away in #22 + #23.)

The good news is that this means this use of service locator instead of dependency injection becomes less brittle, because we can use FQCN::class for it!

Marking RTBC so we hopefully get auto-retesting…

Oh, and do what the issue title says: require PHP >=8 and Drupal >=9.3 (including Drupal 10!).

https://dev.acquia.com/drupal10/deprecation_status/errors?name=cdn%203.x... shows:

Parameter $event of method Drupal​\​cdn​\​EventSubscriber​\​HtmlResponseSubscriber::onRespond() has typehint with deprecated class Symfony​\​Component​\​HttpKernel​\​Event​\​FilterResponseEvent: since Symfony 4.3, use ResponseEvent instead

That's one more thing we should fix here.

Note: Drupal 10 might require PHP 8.1: #3223435: Track PHP 8.1 support in hosting and distributions.

Per #3264819: Require PHP 8.1 for Drupal 10.0.0-alpha2, bumping this to PHP 8.1.

Note to self: all strpos(…, …) !== 0 and strpos(…, …) === 0 occurrences can also be replaced with https://www.php.net/manual/en/function.str-starts-with.php.

I wrote this in #20:

But turns out it's worse. The service ID needs to match the class name. This is … not very useful then. This is also why Drupal core is not yet using it: #3049525: Enable service autowiring by adding interface aliases to core service definitions

Good news! #3049525: Enable service autowiring by adding interface aliases to core service definitions just landed in 10.0.x, during RC! 🤩

Blocked on #3326410: Get tests passing again: core changed config export order + comply with drupal/coder >=8.3.16.

#35: Bad news: #3049525: Enable service autowiring by adding interface aliases to core service definitions was reverted from 9.5.x and 10.0.x, which means the CDN module's 4.x branch can't use it 😬

#3326410: Get tests passing again: core changed config export order + comply with drupal/coder >=8.3.16 landed, and shipped in 3.6, along with a bugfix: #3300982: Drupal core regression: CDN's "far future" responses have wrong Content-Type response header and #3128116: Negated file extensions in file URLs with querystrings or fragments are not recognized correctly.

#3169693: CDN module should override @Filter=filter_html_image_secure implementation to explicitly allow the configured CDN domains is a feature that I'll only add in 4.x minors, as are #2811615: [upstream] [Core bug, fixed since 9.5] AJAX commands that need additional JS to be loaded will fail when JS is loaded from CDN, #3182213: Obtain script errors when loaded from CDN: add `crossorigin` attribute to script tags, #3222572: Add "scheme" condition.

Rerolled #29 on top of the changes mentioned in #38.

Requiring PHP >=8.1 and Drupal >=9.4

Adopt PHP 8.1-only features.

Ran into Symfony's less-than-stellar MASTER_REQUEST-to-MAIN_REQUEST transition again, as described in #3296639-19: Drupal 10 compatibility… 😬

One more oversight — an update test fixture that is obsolete.