Finalize and expose the new logger interface

[sagikazarmark]

Preflight Checklist

• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

A new Logger interface has been introduced to prepare dropping JWW as a dependency (at least from the code, it's still used as the default logger implementation for backward compatibility reasons).

As pointed out in #1268 though, there is no way to provide a custom implementation at the moment. While I don't necessarily see that as a critical problem (JWW works and it's a dependency anyway), we definitely want to drop JWW, so allowing users to customize the logger is inevitable.

Proposed Solution

Expose a WithLogger option for Viper to allow customizing the logger implementation.

Alternatives Considered

No response

Additional Information

Before exposing the interface, we need to finalize it (ie. agree that the current contract is suitable for Viper in the long-term). The current interface is modeled directly after the JWW usage.

Logger abstractions out there:

• Logur: https://github.com/logur/logur
• Logr: https://github.com/go-logr/logr

The contract should be defined by Viper as the consumer of the interface.

[sagikazarmark]

The interface was kept intentionally closed to make sure it's the best we can do.

However, there is some work going on in the Go community to add a structured logger to the standard library. Let's see how that works out, before introducing a custom interface.

[jantytgat]

Any updates on the customer interface? Or switching to stdlib slog entirely?

[sagikazarmark]

Yes, the plan is to switch to slog. I'm working on a solution to make sure we can make the switch in a backward compatible manner.