Allow loading all secrets via separate URI

[clarfonthey]

Right now, the security.INTERNAL_TOKEN_URI option allows loading the security.INTERNAL_TOKEN parameter via a separate file. It would be nice if we could extend this to the other secrets in app.ini as well.

The variables I found that could use this:

• oauth.JWT_SECRET (currently, JWT_SIGNING_PRIVATE_KEY_FILE is used for RSA and ECDSA, but a separate file cannot be used for HMAC)
• server.LFS_JWT_SECRET
• security.SECRET_KEY (Allow specifying SECRET_KEY_URI, similar to INTERNAL_TOKEN_URI #19663)
• service.{RE,H}CAPTCHA_{SECRET,SITEKEY}
• storage.MINIO_{ACCESS_KEY_ID,SECRET_ACCESS_KEY} (and similar sections like lfs and attachment)

Note that this is related to (but not the same as) #4860.

[techknowlogick]

Indeed, we'd be open for a PR for this, as it allows for secrets to be passed via docker/kubernetes secrets etc...

cc: @justusbunsi

[justusbunsi]

I guess it wouldn't be much to do. Should be similar to what was done here. https://github.com/go-gitea/gitea/blob/main/modules/setting/setting.go#L1028

[clarfonthey]

Honestly, the biggest (potential) issue is how the minio/captcha secrets should be loaded, since it would make sense in those cases to group together the credential pair into one file. But yeah, the code for the internal token should mostly cover all the cases we want.

Bonus points if you can make gitea run the various generate commands for non-existent files before running if they don't exist.

[clarfonthey]

Updated issue description to be a checklist for the settings that are converted over, since #19663 implements this for SECRET_KEY.