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.

[wxiaoguang]

Gitea's config system has too many quirks, and has too much specialized code.

I guess it's impossible to do the migration at the moment.

[lunny]

I can have a try. If it's impossible then we can close this one.

[wxiaoguang]

What's the plan? Feasible or not?

[GiteaBot]

We close issues that need feedback from the author if there were no new comments for a month. 🍵

[wxiaoguang]

I do not see it is feasible, so I think it could be closed.

Feel free to reopen with a feasible plan.