AjaxResponseSubscriber should lazily instantiate AjaxResponseAttachmentsProcessor

Only rebased to get the tests to run again since I couldn't run manually. The failure before was random and related to migration not connecting to the database.

All green now.

Refactor seems fine using the autowire, comparing to other instances in core of how it was used.

We have a couple of modules this is going to break. See https://git.drupalcode.org/search?group_id=2&repository_ref=&scope=blobs...

I think we should use the DeprecatedServicePropertyTrait to provide a way for anything that extends the class to access the old property and get a deprecation notice.

Added DeprecatedServicePropertyTrait, not sure it's worth adding a test.

> \Drupal::service('ajax_response.subscriber')->ajaxResponseAttachmentsProcessor;
= Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor {#10035}

Will lean on your committer hat if tests would be needed.

Committed the version without the DeprecatedServicePropertyTrait to 11.x and the version with to 10.3.x.

Committed 5833d31 and pushed to 11.x. Thanks!
Committed 17b4882 and pushed to 10.3.x. Thanks!

Thanks for the excellent issue summary, @longwave! Unless I'm mistaken, this means you've just made all non-HTML responses faster, because those would not use the attachments processor service. IOW: this must've made all JSON:API and REST responses slightly faster? (And presumably GraphQL too.)

It's all non-Ajax responses that are theoretically faster, because the processor is only needed if the response object is an AjaxResponse. But I'm not sure it's measurably faster, as object construction in PHP is relatively fast anyway, and a lot of those services are still needed on many requests, just later on in the request cycle. But if it saves a few nanoseconds here and there then it all adds up eventually!

Automatically closed - issue fixed for 2 weeks with no activity.