Make extension list services tagged services

Part of it done in #1685492: Convert theme engines into services

Unsure if or how to provide BC in the constructor here, but I also don't see why anyone would override this. This issue helps unblock #1685492: Convert theme engines into services where the theme engine list will be deprecated.

Not actually sure these are all cleared anywhere any more, we could add something to the resolver to clear them if necessary but it feels like the wrong place.

Do you mean where reset is called? https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

I was actually looking into that a couple of weeks ago when I thought I needed to reset themes.

Let me look again iirc it was called somewhere for modules but not the other extension lists.

Maybe like this: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

And here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
And here:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

Yeah it's not clear in many cases if we should be resetting one, some, or all. Not sure if we need to mess with any of that here though, if there are no known bugs; in practice the lists do not change often.

I think this is good, but there are a few open questions for me that I'm trying to answer.

1. Were Database extensions intentionally left out? I know they are super weird and always there like theme engines and I know a lot of the list service is intentionally not implemented. I might ping @daffie and @mondrake just to confirm.
2. BC, I tend to agree, nothing we can do without just wholesale deprecation and replacement which I don't think serves any purpose.

I found where it was implemented: #3256642: Introduce database driver extensions and autoload database drivers' dependencies and there is no mention of the path resolver so I think it was just an oversight rather than intentional.

So for 1, I will ping them, for 2 I will ask for other opinions in slack too.

@nixvan as far as I remember, the db driver related implementation was just the minimum necessary to fill the needs of listing them as extensions in the install process. So yes, all what was not necessary was intentionally left out, if that's what you mean.

Thanks @mondrake! That solves concern 1.

I have two minor doc updates as MR suggestions.

I think there is nothing to do for BC here. Once we get those two comments applied I can RTBC I think.

Does this need a CR? Technically it's a BC break, but I don't think it will be for most people using it.

Fixed up the docs, removed database drivers for now, and I wrote a basic change record at https://www.drupal.org/node/3549907

CR and changes look good, only open question is if there is a way to do this and preserve BC. I think this is fine as is though.

Are we sure that we want to do this? This feels like we creating way to extend extension listing. I think the issue summary needs an update to explain the motivation amongst other things.

Copied from a duplicate to the issue summary.

So, the change to ExtensionPathResolver is just to verify the service tag works, right? It would be nice to have that in the proposed resolution section of the issue summary.

Here's your BC example:

  public function __construct(
    #[AutowireLocator('extension_list', 'type')]
    protected ContainerInterface|ModuleExtensionList $extensionLists,
  ) {
    if ($this->extensionLists instanceof ModuleExtensionList) {
      @trigger_error('Calling ' . __CLASS__ . '::_construct() with a ModuleExtensionList as the first parameter is deprecated in drupal:11.4.0 and is removed from drupal:12.0.0. ::__construct() must be called with a single ContainerInterface parameter. See CHANGE_RECORD_URL.', E_USER_DEPRECATED);
      $this->extensionLists = new ContainerBuilder();
      $this->extensionLists->set('module', \Drupal::service('extension.list.module'));
      $this->extensionLists->set('profile', \Drupal::service('extension.list.profile'));
      $this->extensionLists->set('theme', \Drupal::service('extension.list.theme'));
      $this->extensionLists->set('theme_engine', \Drupal::service('extension.list.theme_engine'));
    }
  }

My limited testing showed that it worked. Basically, I reverted the change to ExtensionPathResolverTest and also added a new test function to it that requested the path for the system module. You'll probably need to workshop the deprecation message. I hope you don't mind if I set the issue to Needs Work for you to consider it. I agree that it's probably pointless, but I was so hesitant to review this without BC.