Migrate logging system to log/slog

[TheFox0x7]

Feature Description

if accepted supersedes: #21758
filing as separate proposal due to a slightly different scope with the same outcome and names specific provider instead of just outcome.

With the introduction of go 1.21 log/slog was added to standard library. It's a structured logging library that allows to log a message with a key-value pairs added to it for later processing. It provides two formatted loggers (plus built-in default) json and logfmt

Why slog instead of zerolog or zap? It's in the standard library. I don't have a strong reason for/against alternative libraries.

As for why I feel it's worth migrating:

Benefits

• It is very helpful when making statistics from logs with tools like angle-grinder, loki and similar tools
• It's easier to filter through logs as you can set more complex filters to narrow the search down to specific context or exclude noise instead of just grepping through (though that doesn't go away).
• Easy to include and find context for the log, for example when logging error in caused by a user, userid can be added as an attribute to look for later, which could be helpful for abuse detection via logs.
• Third party extensions (such as sampling or some specific sinks) are available.
• Specific loggers can write to the same file separated with an attribute

Drawbacks

• Requires modifying all log lines in current codebase from printf to structured. For the switch current logs could format the message with sprintf so the change wouldn't have to be done in one go but in chunks.
• I believe support for adding, pausing and removing loggers would require custom handler or io.Writer.
• It's a breaking change unless a custom handler to print old style is added.
• Access logs might be an issue to port (if they would be ported to this at all).

Screenshots

No response

[TheFox0x7]

@wxiaoguang seeing that you refactored/touched logging last do you have any views on this?

[wxiaoguang]

Thank you for the proposal. IMO it's more complicated than it looks, while at the moment I don't have time for it ...

[TheFox0x7]

np. I'd like to implement this but (similar to otel) I figured it's better to talk this through before fully committing to it to avoid wasting time.

[wxiaoguang]

At the moment, my priorities are: make sure the code is maintainable and fix bugs, review and help to improve some PRs whose changes are clear, implement some widely-requested features.

For the "slog" migration: I am not sure whether there is a maintainable/feasible way to introduce it: whether the related PRs can be clear, how much end users would really need it or benefit from it (because many logs are just noises).

---

The Gitea's log system is really complicated, and there are many abuses, TBH I don't see how the "migration" would succeed at the moment.

If you'd really like to try, I think we need a progressive design & plan. As the first step, I think we need to decouple most CLI commands from the current logger, because most CLI commands should just output messages to stdout/stderr directly like normal POSIX programs, and the CLI commands should not be affected by the "logger" config options.

Update: "decouple most CLI commands from the current logger" is still very hard, due to the how the "setting" package uses the logger, and the "setting" package itself is also problematic.