Fix settings not being loaded at CLI

[cassiozareck]

Closes #25898
The problem was that the default settings weren't being loaded, so

gitea/models/user/user.go

Line 593 in ad69f71

u.AllowCreateOrganization = setting.Service.DefaultAllowCreateOrganization && !setting.Admin.DisableRegularOrgCreation

was always false.

[silverwind]

I wonder if this is really the right place to load the settings or if we should do it earlier. Doing it in the middle of command processing does seem odd.

[cassiozareck]

Both way works as of my tests. I thought to initialize together with the DB but thinking better at the beginning may be more clean. I'll adjust it

[silverwind]

Ah I see the context now, previous place was fine then I guess, the validation does not depend on settings it looks like. Note I'm not really knowledgeable around these parts so take my comments with a grain of salt :)

[cassiozareck]

As we're loading settings there's happening some output when a user runs gitea admin user create. Like this:

2023/08/11 10:34:13 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled
2023/08/11 10:34:13 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled
2023/08/11 10:34:13 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled
New user 'user1' has been successfully created!

[silverwind]

That reinforces that it needs to be after validation.

[cassiozareck]

Hmm so its ok? I think its unavoidable unless we try to change the config for logging outputs before

[silverwind]

Just revert to previous location imho.

[cassiozareck]

Oh no no! It happen doesn't matter where loadsetting is. There's log statements inside loadsettings. I think its alright as it states settings are being loaded but if you dont want log to happen I can see what I can do. I know I caused some confusion because it looked like I was saying because of position. Pls dont avoid my PRs 😆