Simpler and faster jsonKeys implementation

[suzaku]

It turns out the simpler way that just use json.Unmarshal is faster than calling Decode to parse it manually.

name               old time/op    new time/op    delta
JSONKeys/short-12    2.54µs ± 1%    1.60µs ± 2%   ~     (p=0.100 n=3+3)
JSONKeys/long-12     5.61µs ± 0%    3.61µs ± 0%   ~     (p=0.100 n=3+3)

name               old alloc/op   new alloc/op   delta
JSONKeys/short-12    1.64kB ± 0%    1.06kB ± 0%   ~     (p=0.100 n=3+3)
JSONKeys/long-12     2.74kB ± 0%    1.30kB ± 0%   ~     (p=0.100 n=3+3)

name               old allocs/op  new allocs/op  delta
JSONKeys/short-12      45.0 ± 0%      20.0 ± 0%   ~     (p=0.100 n=3+3)
JSONKeys/long-12       89.0 ± 0%      37.0 ± 0%   ~     (p=0.100 n=3+3)

[sonarcloud[bot]]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
0.0% Duplication

[suzaku]

Never mind. It seems write depends on the order of keys and assumes that "timeField" is the first key.

[phuslu]

Thanks. Yes, iterate on a golang map will get a shuffled/random order. So jsonKeys was introduced because internal users ask for "fields should keep orderred" feature on ConsoleWriter

[suzaku]

I believe we can do better, because parsing keys only takes longer than decoding the while JSON just feels wrong. That said, it won't be an easy job unless we use some other JSON library.

[phuslu]

Agreed.

To keeps "No Dependencies" feature, I'm looking for a simplified/bundled JSON parser like,

1. pkg/json https://github.com/pkg/json
2. gjson https://github.com/tidwall/gjson

I'm considering how to implementing a "only top level" json parser base on their codes.