Gitea: Migrate configuration to github.com/spf13/viper

[sapk]

Since https://github.com/spf13/viper/releases/tag/v1.6.0, viper support INI file config.

What do you think of migrating to this library to store config in various format (INI, Toml, Env variable, etcd, consul, ...) ?

I think this would remove a lot of code logic from gitea and help readability of the config code.
This would also ease the compatibility with container environnement via env variable or distributed config manager support (etcd, consul)
This would also ease the compatibility with FHS linux distribution by looking at multiple standard path for configuration.
Another point, this would allow support for live reloading of some configuration (and maybe could be used by UI) but this would not be the primary goal.

Somewhat related issues/change that could be replaced: #7287 #6923

[lunny]

I think we can try and PRs are welcome.

[davidsvantesson]

Shouldn't we try to make more admin configuration available in the UI? Would that be possible with this or would that require moving settings to database?

[techknowlogick]

I think a migration to this would be useful, as it can also allow configuration changes to be made without a binary restart, as well as non-ini config formats.

I am a bit biased as I was the one who created the PR to viper to get INI support added.

As this is a non-breaking change, I prefer we do this before evaluating moving to a UI based approach.

[guillep2k]

Is it possible to select from code which values can be "hot-loaded" and which should remain freezed? I didn't check our code in depth, but I believe there are groups of settings that need to be consistent as a whole; allowing changes to some of the values without a group revalidation could produce invalid results.

Maybe we should make a list of the settings that we expect to be automatically reloaded (e.g. log level?) and which don't (install dir?).

[renothing]

5070

part1: readonly variables with startup
part2: changeable variables write to db with hot reload.