Fork Symfony's ContainerAwareTrait and ContainerAwareInterface into core

Adding what this is postponed on to the remaining tasks per Remining tasks.

Changing parent to the S7 compatibility issue, so we find all the related issues.

But maybe someone wants to review the current state, so leave it on NW on my name for now.

Hmm. This looks like a situation where the new tag "Needs architectural review" can help. Adding tag and setting to NR.

The event dispatcher just receives the entire container as an argument:

  event_dispatcher:
    class: Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher
    arguments: ['@service_container']

Can we just do this for the services that need it instead of copying the ContainerAware feature?

It just means injecting the whole container as a service via a constructor argument, instead of using the ContainerAwareTrait/Interface helpers.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

As I see in the MR5181 is the trait is removed but not replaced with fork, so summary needs update

Issue title said we gonna fork but MR doing replacement which is better to do as rector's rule to be reusable for contrib/custom code

IMO fixing just a namespace is preferable way, with follow-up to remove usage as the change very disruptive

Believe #13 is enough for NW? If not feel free to put back.

I've already hit this as in our project we're rejecting code triggering deprecations. It happened when some dependency updated Symfony from 6.3.5 to 6.4.1. Not sure whether to apply this patch or to pin Symfony

Here's a small patch to remove the deprecation from Symfony because you can't pin to 6.3.5 and use Drupal 10.2.1

So it looks like in many of these cases we should be using service locators instead of injecting the entire container:

Sometimes, a service needs access to several other services without being sure that all of them will actually be used. In those cases, you may want the instantiation of the services to be lazy. However, that's not possible using the explicit dependency injection since services are not all meant to be lazy.

CacheFactory, CacheTagsInvalidator, CheckProvider, StreamWrapperManager, KernelDestructionSubscriber all look like they could use this technique.

EntityTypeManager and ClassResolver are more tricky and need access to the entire container, but I think we could just inject the container as a service in these cases.

Actually, KernelDestructionSubscriber can't use this because a service locator is a separate mini-container, and the destructor needs to know if each individual service was actually used in the main container.

Opened #3414625: Convert KernelDestructionSubscriber to use configurators for a slightly hacky way of dealing with KernelDestructionSubscriber.

Opened #3414627: Convert StreamWrapperManager to use a service locator to try out using a service locator in StreamWrapperManager.

#3412556: Allow needs_destruction services to run on page cache hits removes KernelDestructionSubscriber entirely, so #3414625: Convert KernelDestructionSubscriber to use configurators can be closed if that lands.

Opened #3427741: Notify downstream users that ContainerAware is going away which would mean this can be closed as won't fix.

#3427741: Notify downstream users that ContainerAware is going away landed and we should be able to remove ContainerAware support entirely from Drupal 11 in #3431362: Remove support for ContainerAwareInterface.