legacy config.py files may prevent the web applications from starting or break functionality

[zenmonkeykstop]

Description

See #5757 - instances without the SESSION_EXPIRY_MINUTES attribute defined in config.py were failing to start after a code update that assumed all required attributes were defined was pushed. This was fixed in #5759 but other problems may lurk in older config files.

It might be worth:

• looking at historical updates to config.py to figure out what attributes were added and when, and making sure they're handled correctly in future code updates
• figuring out how to better manage app config (@heartsucker had a long-running PR for this that I can't find now - another option is to move more attributes into the database)
• figuring out how to update config.py to a valid state during an application update

[eloquence]

Old PR by @heartsucker: #3850
Old, related issue: #1966

[emkll]

During the 1.7.0 release postmortem, other suggestions were proposed by the team:

• Testing historical possible versions of config.py
• Separating the configuration between private (salts, secrets) configuration and public (common configuration)
• Move as much configuration as possible to the database
• Add logic to the restore script, to "update" the configuration to the update the configuration with the latest/expected values

Given the complexity of this logic, but also the state being different across instances based on when the instance was first set up (config.py is carried over via backups but is not touched by the application role on subsequent installs), we should perform a timeboxed investigation to carefully review the current implementation, and propose next steps (which may include one or more tasks included in this thread)