log: remove custom json and logfmt handlers

[holiman]

Potential follow-up to #28622

This PR removes our custom json and logfmt implementations, to instead use the ones built into slog. Ours does some transformations under the hood, mainly renaming time to t and level to lvl, and de-capitalizing the levels.

It also does away with the custom key-value pair "filling". Instead of
key=<nil> LOG_ERROR="Normalized odd number of arguments by adding nil" slog simply says BADKEY=key

The one other thing worth mentioning is that this makes the json output spit out *big.Int types as json-native numeric format, e.g 111222333444555678999 instead of "111222333444555678999". When trying to read that back into any, the unmarshaller selects float64, which cannot read it fully correct on the way back.

I think it would be better to switch over to slog, if we believe that slog is some kind of go-idiomatic future of logging. A few of our users may potentially have to switch over their parsing, but all in all it's probably not a great amount of work, and probably something that's better done sooner rather than later.

[holiman]

Triage for discussion

[holiman]

triage discussion: check on twitter if any users of logfmt/json yell

[lmittmann]

shameless plug: https://github.com/lmittmann/tint a pretty slog.TextHandler like handler. It provides the same ReplaceAttr-logic as slog.{Text,JSON}Handler.

[karalabe]

triage discussion: check on twitter if any users of logfmt/json yell

Taylor G. wrote back that it does break graylog collectors.

Are we saving anything performance wise to make it necessary to do the change? The extra code is not really meaningfully large. My 2c currently is not to break it as there's no real gain in having t vs time.

[karalabe]

shameless plug: https://github.com/lmittmann/tint a pretty slog.TextHandler like handler. It provides the same ReplaceAttr-logic as slog.{Text,JSON}Handler.

Unless it is significantly faster than what we use currently (also it needs field alignment), it's probably simpler to keep the current code vs introduce new dependencies.

[holiman]

shameless plug: https://github.com/lmittmann/tint a pretty slog.TextHandler

Btw, I meant to say (but forgot): I looked at that earlier, looks really neat. I'm probably going to use that in some project down the line, but I think we should maybe not use it for geth.

[holiman]

Unless it is significantly faster than what we use currently (also it needs field alignment), it's probably simpler to keep the current code vs introduce new dependencies

Fair enough. Tho we should probably just drop the key=<nil> LOG_ERROR="Normalized odd number of arguments by adding nil" handling anyway, for simplicity.