Use log/slog for logging

[vishnureddy17]

Go now has a nicer logging package in the standard library. It might be better to use that if the Go ecosystem is going to converge on that.

[MattBrittan]

Our current Logger is:

Logger interface {
        Println(v ...interface{})
        Printf(format string, v ...interface{})
    }

This is a subset of log.Logger so can be used with slog pretty easily:

h := slog.NewJSONHandler(os.Stderr, &slog.HandlerOptions{Level: slog.LevelDebug})

cliCfg := autopaho.ClientConfig{
    Errors:         slog.NewLogLogger(h.WithAttrs([]slog.Attr{slog.String("source", "autoErrors")}), slog.LevelError),
    Debug:          slog.NewLogLogger(h.WithAttrs([]slog.Attr{slog.String("source", "autoDebug")}), slog.LevelDebug),
    PahoErrors:     slog.NewLogLogger(h.WithAttrs([]slog.Attr{slog.String("source", "pahoErrors")}), slog.LevelError),
    PahoDebug:      slog.NewLogLogger(h.WithAttrs([]slog.Attr{slog.String("source", "pahoDebug")}), slog.LevelDebug),
...

Of course this does not enable the library itself to output structured messages.

Advantages of using slog:

• Standardisation - seems quite likely slog will gain popularity (but difficult to assess this) - but log.Logger is an older standard.
• Easy to use for those using slog (but pretty easy to use existing logger)
• Could add structure to paho logs (but as these are almost solely used for debugging the library I'm unsure if this adds much value).

Disadvantages of using slog:

• Complicates basic usage (very simple to implement current logger)
• More difficult to use when user is not using slog (need to find adapter and there may be limitations)
• Performance (slog likely to be slower; other log libraries outperform it)

I'm on the fence with this one; the above was really me trying to put my thoughts in order! Either way the logging could do with some work...