Improve settings management and documentation

[thclark]

Feature request

Use Case

Both users and developers of the library need a clear overview of what settings are available and what they do.

Current State

Settings are reasonably well documented individually, but are scattered throughout the documentation according to the different parts of the library.

It would be good to have a clear view of the settings:

• In a centralised place in the documentation
• In the library source code itself (Within the library, a different approach is taken to settings management depending on where the code came from, eg originating from django-storages, django-cloud-tasks or written by octue).

Further, it could be good to have clearly namespaced settings eg GCP_STORAGE_. Some progress has been made toward this.

Proposed solution

• A single settings manager would help give developers a clearer view of everything going on.
• Add the individual settings to it in a way suitable for autodoc
• Autodoc the settings in a single "settings index". Do it value by value, and arrange the documentation by namespace so that, for example, the storage documentation can point to it.

Heed the following note made in the Task Manager:

# A note on the @property style of using django settings:
#
#   In many django libraries, it's commonplace to inspect and validate
#   the relevant django settings on start of the app, often adding them as
#   attributes to a controller or manager class like this TaskManager.
#
#   However, that's a much-misunderstood antipattern. The reason is that
#   in testing, the client app is instantiated on set up of the test, then
#   any variation in settings required for the test (i.e. applied with the
#   @override_settings decorator) is applied afterward... so while a
#   setting might change, any *copy* of it won't, so the test doesn't work.
#
#   There are two ways around this; either have a settings handler that
#   listens to the `setting_changed` signal, or directly access the relevant
#   setting each time. Here we do the latter (the storage module does the
#   former, as the storage settings are more complicated). By using
#   properties to get those settings, we have an easy access and a single
#   location where defaults are defined.