Allow root owned config.

It would be good to fully support read-only configs, in order to be able to support a setup where the config is owned by root in /etc/nextcloud/ for example. This increases security, and better supports packaging Nextcloud into Linux distributions.

With some minor tweaks to the code, I have successfully managed to run Nextcloud as described, and have managed to perform an upgrade successfully by manually making changes to the config.

In order to accomplish this properly, these are the changes I believe are needed:

• In order to run Nextcloud normally with a root owned config, Nextcloud should check for the owner of the datadirectory instead of the config file (given this is the only thing it should be editing). (#27613, #45307)
• Regression in v24+: #44039
• For upgrades, Nextcloud should use the database to store non-user options during the upgrade process, rather than editing the config file.
  • The loglevel could be set in the DB, and then perhaps the lowest value between the config and the DB is the level used. This way the upgrade process can set debuglevel to 0 in the DB, and then unset it after completion, leaving the user's setting alone.
  • maintenance could be set in the DB, with maintenance mode being enabled if the flag is found in either the config or DB. Again, the upgrade can then set this in the DB, and unset it after upgrade.
  • version could be set in the DB. Surely the release number is primarily used to ensure the DB is upgraded? Therefore the value belongs in the DB and not with the user config. (This makes me wonder what might go wrong if someone imports their database from a backup, but are still using the current config file with a newer release number and the imported DB is then in the wrong state.)
• Additionally, Nextcloud should avoid writing default settings to the config. When upgrading, it wanted to write "'theme' = ''", which is the default value if not present.
• If Nextcloud really does need to update a value in the config, it should pause the upgrade and tell the user what value needs to be changed/added and then allow the user to continue the upgrade after manually updating the config.

The issue names no files, tests, or entry points and combines normal operation, upgrade behavior, database state, and config-writing requirements. Start by separating the checklist items and tracing the existing config and upgrade paths; done would require implementing and validating the agreed behavior for root-owned, read-only configs.