Plugin apps load at unexpected time in Django startup (no settings available)

Because we tell devs to call add_plugins from inside their Django settings module (DSM), and because that immediately imports the plugin app's code, the app's module initialization occurs at an unusual time for a Django app.

Specifically, any code like SOME_FEATURE = getattr(django.conf.settings, 'SOME_FEATURE', 'default') will always get 'default', rather than the configured value. In one case this caused a circuit-breaker setting not to be usable. The reason this happens is that django.conf.settings isn't usable until the entire DSM has been imported by Django during startup; if the plugin app is loaded during this time, no settings will be available. Normal apps are loaded by Django strictly after the DSM is loaded (since INSTALLED_APPS is one of the settings).

The documented workaround for this is to have plugin apps load settings only inside functions that are called at normal runtime, such as ready(). However, there may be other surprises. We may want to change our plugins utility to ensure apps are loaded by Django directly. It may be possible to do this without changing how we write settings file (perhaps by having the plugin framework itself only load the plugins in a ready() method of its own, or similar).

Trace the add_plugins entry point and how plugin apps are imported from the Django settings module. Compare that flow with Django's normal app loading and the documented workaround of reading settings in ready(). Define and test a loading approach that makes settings available before plugin app module initialization, while preserving plugin configuration usage.