Clean up NestJS providers for dependency injection

[sbliven]

Summary

NestJS expects to manage the instantiation of providers (eg any classes marked @Injectable() as well as some less common provider definitions). Instead they should be provided by a single module. That way NestJS creates a singleton instance available across the app.

SciCat should remove cases where providers are instantiated and replace these with dependency injection (DI).

Steps to Reproduce

The effect can be seen by putting a logging statement in a provider constructor. For instance, the CaslAbilityFactory is instantiated 13 times; configure() gets called several places directly rather than via ConfigService, AuthService is provided twice, etc.

Current Behaviour

Multiple instances are harmless as long as the provider doesn't have dependencies or side effects. However it might decrease performance and it doesn't follow best practices

Expected Behaviour

• Providers are provided in a single module and exported
• Other providers that need access to the singleton should do so via dependency injection
• Tests may need to construct a TestModule to ensure DI gets called.

Details

#1539 removes many of the CaslAbilityFactory instances and includes some examples of how to construct the TestModules. In many cases the entire module can just be mocked, avoiding dependency injection.

[sbliven]

I propose putting this on hold until after #1539 (and the rest of release-jobs) gets merged into main.