Switch to slog for structured logging

[dennwc]

Currently, sipgo uses zerolog for structured logging. Even though this is one of the fastest structured loggers, there are other alternatives that upstream projecs may use (e.g. zap).

This change switches sipgo to stdlib's log/slog package, which can be configured by the developer to use any existing logger implementation:

• zerolog: slog-zerolog
• zap: official zapslog, unofficial slog-zap
• logrus: slog-logrus

Using a single logger implementation between sipgo and the main application allows attaching relevant SIP logging context to the high-level application logs.

[emiago]

Hi @dennwc . I would see maybe this as big shift.
I do configure/use zerolog on other projects. I need to know understand more myself all of this latest changes.
This thing was better to be more a issue, as it maybe always conflict, and it is big shift that I myself need to take into account due to other libs I have. If you have just opened issue, I may have considered to be moved for you.
I will have to put this on hold

[emiago]

Note of possible drop performance
rs/zerolog#571

[dennwc]

This thing was better to be more a issue ...

Indeed, this is something that needs a longer discussion. I opened a PR instead of the issue because we already have it implemented in LiveKit's branch of sipgo that we use. We would really like to upstream the changes we have and switch to upstream.

I need to know understand more myself all of this latest changes.

Definitely! No rush, please take your time.

The conversion was 1:1, except a few places where the log calls were adding some common parameter. I rewrote those places to share a common logger var (e.g. in TXes) that sets logging parameters upfront (key in case of TX).

as it maybe always conflict

I'm totally okay with updating this PR from time to time while the PR is in review.

I do configure/use zerolog on other projects.
... it is big shift that I myself need to take into account due to other libs I have.

I totally understand your concern about having to switch the logging library in other projects.

But I assure you, you won't need to switch away from zerolog in other projects. Calling slog.SetDefault(...) and passing one of the adapters I linked should work flawlessly.

This is the main reason for this change, actually. We use Zap internally, and also are hesitant to switch to a different logger or have to configure multiple loggers. With this change, any structured logger can be used without conflicts.

Note of possible drop performance

Correct, comparing to zerolog, there will be a minor performance hit. From what I understand, it's mostly due to calls to runtime.Callers which other logging libraries require to show the call site anyway.

In general, if you are concerned about logging performance in sipgo, there are other low-hanging fruits for improving performance. For example, calls to .String() in logging parameters always cause allocation, even if the log is disabled due to the logging level. So removing these could improve performance and reduce garbage.

Same is true for this PR as well - it's not ideally optimized. It passes logging parameters as any, but for the best performance it's advised to use slog.Value constructors. Similar to how zerolog provides .Int and other typed helpers.