Improve install code to avoid low-level mistakes.

[wxiaoguang]

Background

• Many users do wrong to their Gitea instances. When they upgrade or migrate, they do "install" without the old app.ini, which causes many problems (described in the screenshot)
• An old PR (Add internal routes for ssh hook comands #1471) made Gitea create empty(wrong) app.ini if the target file doesn't exist. This confuse many users and hinder users to find the correct app.ini, some issues mentioned in Use LDFLAGS to set the default locations in docker #17501 are actually caused by this strange behavior. This PR will avoid such low-level mistakes

Solution

If a user tries to do a re-install in a Gitea database, they gets a warning and double check.
When Gitea runs, it never create empty app.ini automatically.

This PR also includes some small (related) refactoring:

• Refactor db.InitEngine related logic make it more clean (especially for the install code)
• Move some i18n strings out from setting.go to make the setting.go can be easily maintained.
• Show errors in CLI code if an incorrect app.ini is used.
• APP_DATA_PATH is created when installing, and checked when starting (no empty directory is created any more).

Screenshot

[zeripath]

If I understand things correctly there are two problems that you want to handle:

1. If Gitea doesn't find an app.ini where it expects to find one, it will simply attempt to create one and the secrets contained therein. When this is coupled with Gitea's default app.ini location not always being where users expect it then you get some repeated issues. (As an extension to this Gitea will attempt to create other things too.)
2. Gitea doesn't warn that it's re-running the install page even if the db and/or app.ini was already extant.

I think this PR is eliding the empty app.ini and the non-set INSTALL_LOCK here.

---

It would be helpful to split our commands in to two or three sets:

• Commands which are allowed to create app.ini
  • gitea web
• Commands which should not create an app.ini but are allowed to function with install lock not set by default
  • gitea cert
  • gitea embedded
  • gitea generate - should not overwrite SECRET_KEY without warning (Possibly allow to create an app.ini?)
  • gitea doctor
  • gitea convert - needs DB config
  • gitea recreate-table - needs DB config
• Commands which should not create an app.ini but could be allowed to function with install lock not set by default if we make install not destroy SECRET_KEY
  • gitea admin - will require SECRET_KEY to be set
  • gitea migrate - will require SECRET_KEY to be set
• Commands which should not create an app.ini and should not function without a lock or secrets
  • gitea dump - needs SECRET_KEY
  • gitea keys - needs INTERNAL_TOKEN
  • gitea manager - needs INTERNAL_TOKEN
  • gitea dump-repo
  • gitea restore-repo
  • gitea serv - needs INTERNAL_TOKEN
  • gitea hook - needs INTERNAL_TOKEN
  • gitea migrate-storage

Then it would useful to think about when we can run the install page:

• Clearly if the DB is extant we should be querying the wisdom of running the install page - but it may be reasonable to allow except:
• As the install page currently stands it always overwrites the SECRET_KEY. This is a serious problem if the DB is already extant and SECRET_KEY already present - so we need to make sure that doesn't happen.
• There are several other secrets in there that are less problematic.

---

I guess we therefore need instead to adjust setting.NewContext to at pass in whether it's expected to write to the app.ini - which could handle at least part of the first part of the problem.

(We could then add two global options --no-create-app-ini and --allow-create-app-ini which could then force things.)

Then we'd handle the rest of the special conditions in a consistent way.

[zeripath]

We might finally have a more sane behaving system after this is in.

I still think setting the LDFLAGS for the docker is the right thing to do but at least this way people will get a clear warning when they're running gitea commands without the correct environment or not having passed the correct config file option.

[wxiaoguang]

We might finally have a more sane behaving system after this is in.

I still think setting the LDFLAGS for the docker is the right thing to do but at least this way people will get a clear warning when they're running gitea commands without the correct environment or not having passed the correct config file option.

I agree that Docker usage is really a problem. And the patch works for Docker users.

My thoughts: we have made many splitting behaviors before (binary build, snap build, docker build, docker-rootless build, maybe deb/rpm builds), if we continue to introduce different behaviors to different builds, it will confuse many users and developers in future. If there is one possible way to unify these behaviors, I will try.

Even if we patch the Docker's behavior, there are still snap users, deb/rpm users, they may all be affected by the Gitea's strange app.ini mechanism.