refactor: prepare to decouple the "model migration" package and "models" package (#38533)

Migrations should never use model structs directly, because the model
structs can be different in different releases. e.g. if one migration uses
"User" model, it works in the early releases, then one day, when the
User model changes, the migration breaks because it will use the
new (incorrect) User model, it should only use the old User model.

The same to "modules/structs".

---------

Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>

docs/build-source.md

@@ -53,10 +53,10 @@ For packagers who need to use paths like `/etc/gitea/app.ini`,
 they should define these values at build time for `make build` by environment variable like
 `LDFLAGS='-X "module.Var1=Value1" -X "module.Var2=Value2"' TAGS="bindata" make build`.
 
-- _`CustomConf`_: `-X "code.gitea.io/gitea/modules/setting.CustomConf=/etc/gitea/app.ini"`
-- _`AppWorkPath`_: `-X "code.gitea.io/gitea/modules/setting.AppWorkPath=/var/lib/gitea"`
-- _`CustomPath`_: `-X "code.gitea.io/gitea/modules/setting.CustomPath=/var/lib/gitea/custom"`
-- Default PID file location: `-X "code.gitea.io/gitea/cmd.PIDFile=/run/gitea.pid"`
+- _`CustomConf`_: `-X "gitea.dev/modules/setting.CustomConf=/etc/gitea/app.ini"`
+- _`AppWorkPath`_: `-X "gitea.dev/modules/setting.AppWorkPath=/var/lib/gitea"`
+- _`CustomPath`_: `-X "gitea.dev/modules/setting.CustomPath=/var/lib/gitea/custom"`
+- Default PID file location: `-X "gitea.dev/cmd.PIDFile=/run/gitea.pid"`
 
 Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable and run `make build`
 with the appropriate `TAGS` as above.

docs/development.md

@@ -109,7 +109,7 @@ which lives in the [documentation repository](https://gitea.com/gitea/docs).
 ## Database migrations
 
 If you make breaking changes to a database-persisted struct under `models/`, add a
-new migration in `models/migrations/`. See [testing.md](testing.md#migration-tests)
+new migration in `modelmigration/`. See [testing.md](testing.md#migration-tests)
 for running the migration tests.
 
 ## Testing

docs/guidelines-backend.md

@@ -23,7 +23,7 @@ The backend is split into top-level packages, each with a focused responsibility
   dependencies to a minimum
   - `models/db`: core database operations
   - `models/fixtures`: sample data used by tests
-  - `models/migrations`: schema migration scripts
+- `modelmigration`: schema migration scripts
 - `modules`: standalone functionality with few dependencies
   - `modules/setting`: configuration handling
   - `modules/git`: interaction with the Git command line

docs/testing.md

@@ -136,7 +136,7 @@ Useful environment variables:
 ## Migration tests
 
 If you change a database-persisted struct under `models/` you will usually need a
-new migration in `models/migrations/`. Run the migration tests with:
+new migration in `modelmigration`. Run the migration tests with:
 
 ```bash
 make test-migration