Move models/db to modules/db

[delvh]

This fixes quite a few imports to models inside modules.
In addition, it is the conceptually better fitting place for a package that has no application-specific dependencies but a lot of dependents.

[delvh]

Why does the linter fail, even though my local make fmt doesn't change anything?

[zeripath]

Not sure about this. The idea was that modules would not be dependent on db or the models.

Why does this help?

[delvh]

In theory, I absolutely agree.
But then please explain to me why the changes between https://github.com/go-gitea/gitea/pull/22881/files#diff-df6792f0bd4f2d349508731c08110a47e5cf0c9559f863f9bb5d7c37cd4f1240 and https://github.com/go-gitea/gitea/pull/22881/files#diff-fa07e296d614e796de67f7ae9268a0660b89c09b6e5f6373b4ca7bf76a20dec7 were necessary…
Apparently, that rule wasn't kept previously.
I'm simply trying to untangle this import mess we've already produced to stay consistent with what our Docs say on how Gitea is structured (https://docs.gitea.io/en-us/guidelines-backend/#package-dependencies).
And as I said in the body of this PR, you can even argue that modules is a better root package for this package, as it only depends on modules/settings, and nothing else. And as shown above, even a lot of already existing code in modules depends on it.

[wxiaoguang]

I think the db package is better to be kept in the models package, and refactor other dependencies.

The reason of putting the db package in models is that they are all database-related, while modules should do their best not touch database directly.

The purpose of defining the dependency order is to make the structure clear, and sometimes it's just difficult to strictly follow that pre-defined order.

My opinion is:

• Do the best to keep the structure import order (say, just do the best, but not strictly follow)
• If the db in the models is by purpose and clearer, I think it's good to keep it there, while refactor other packages.
• If the benefit is not big enough, keep restraint for refactoring

I drafted a refactoring guideline in #22880 (I have experiences for maintaining systems which are 10 years old and refactoring them to modern, there are some my opinions to share).

[lunny]

Looks like there is no difference between putting db in models or modules, so we can keep it as before.

[delvh]

This refactoring seems to be unwanted.

[zeripath]

@delvh thanks for trying though!

We should instead finish the move to make the dependency tree:

routers -> services -> models -> modules

So if a package in modules relies on models it should be moved to services or reconsidered entirely

[delvh]

😒 That's what this PR attempted to do in the least intrusive way.
Everything else will result in equivalent behavior, but with a lot more refactoring work.