...either by making each provider into a service,There are two somewhat distinct applications of dependency injection that should be considered:
* Injecting the providers into AuthManager (and making it a service instead of a singleton). Right now the AuthManager class and the configuration logic deciding what providers to use are strongly coupled. It should be possible to create other AuthManager instances with different sets of providers. or by providing a separate `ServiceContainer` in which the providers can be items.
The main use case for this is extension configuration: providers defined by extensions need two `Config` instancesThis would be helpful for extensions which do programmatic account creation (such as TranslateSandbox) and right now have to hope that no provider is registered which would interfere with the non-interactive account creation projects.
* Injecting dependencies into each provider, one for core and one for the extension.either by making them into separate services, Currently the core config is supplied via setter injection and the extension one via ugly hacks.
`$wgAuthManagerConfig` (or maybe `ObjectFactory`?) should presumably be changed so that it can take a service name instead of a class name + argsor by providing a dedicated `ServiceContainer` for AuthManager in which the providers can be items. The main use case for this is extension configuration: providers defined by extensions need two `Config` instances, one for core and one for the extension. Configuration settings for which it makes sense to keep them in `$wgAuthManagerConfig` (such as `authoritative`) should become setter parameters instead of constructor parameterurrently the core config is supplied via setter injection and the extension one via ugly hacks.