refactor: use gojson to marshal config for SHA

[pmalek]

What this PR does / why we need it:

Use gojson to marshal config to JSON to get config SHA.

This speeds up the marshalling of config to JSON by about 35%, using roughly the same amount of memory and the same amount of memory allocations.

Results (run locally):

$ benchstat /tmp/old /tmp/new
goos: darwin
goarch: arm64
pkg: github.com/kong/kubernetes-ingress-controller/v2/internal/dataplane/deckgen
                      │  /tmp/old   │              /tmp/new               │
                      │   sec/op    │   sec/op     vs base                │
DeckgenGenerateSHA-10   31.32µ ± 0%   20.25µ ± 1%  -35.36% (p=0.000 n=10)

                      │   /tmp/old   │              /tmp/new               │
                      │     B/op     │     B/op      vs base               │
DeckgenGenerateSHA-10   10.95Ki ± 0%   10.87Ki ± 0%  -0.70% (p=0.000 n=10)

                      │  /tmp/old  │            /tmp/new            │
                      │ allocs/op  │ allocs/op   vs base            │
DeckgenGenerateSHA-10   12.00 ± 0%   12.00 ± 0%  ~ (p=1.000 n=10) ¹
¹ all samples are equal

Results can be observed at https://kong.github.io/kubernetes-ingress-controller/dev/bench/ for 2501474 or at https://github.com/Kong/kubernetes-ingress-controller/actions/runs/5377294841

Special notes for your reviewer:

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[codecov]

Codecov Report

Patch coverage: 100.0% and project coverage change: -0.1 ⚠️

Comparison is base (9ec5633) 62.6% compared to head (6d0ea66) 62.6%.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #4222     +/-   ##
=======================================
- Coverage   62.6%   62.6%   -0.1%     
=======================================
  Files        153     153             
  Lines      17006   17006             
=======================================
- Hits       10656   10655      -1     
+ Misses      5685    5683      -2     
- Partials     665     668      +3     

Impacted Files	Coverage Δ
internal/dataplane/deckgen/deckgen.go	47.7% <100.0%> (ø)

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[czeslavo]

Do you think it would be worth noting in the changelog? IMHO we could mention it in the "Under the hood" section, WDYT? It's a performance improvement and it might be worth making such changes visible to the users.

[pmalek]

Do you think it would be worth noting in the changelog? IMHO we could mention it in the "Under the hood" section, WDYT? It's a performance improvement and it might be worth making such changes visible to the users.

I believe so, yes. Just wanted to gather feedback from the team beforehand.

[czeslavo]

Are there any objections to using gojson that we're aware of? 🤔

[rainest]

I'm ambivalent on a changelog entry since the SHA computation isn't something you usually think too much about. Can't think of objections--they say they're compatible with the stdlib version, so as long as they don't break that I wouldn't expect issues.

Should we not also use this elsewhere we're currently using json.Marshal and json.Unmarshal? The internal/dataplane/sendconfig/inmemory.go in particular is operating on a similarly large struct.

[pmalek]

I'm ambivalent on a changelog entry since the SHA computation isn't something you usually think too much about. Can't think of objections--they say they're compatible with the stdlib version, so as long as they don't break that I wouldn't expect issues.

I've added the changelog entry as that's something that people may refer to in case we'll observe performance gains.

Should we not also use this elsewhere we're currently using json.Marshal and json.Unmarshal? The internal/dataplane/sendconfig/inmemory.go in particular is operating on a similarly large struct.

We should definitely consider this but first: measure! Add a benchmark, gather some data points (so that it's visible at: https://kong.github.io/kubernetes-ingress-controller/dev/bench/) and then propose a patch so that we can observe the change (and claim the bragging rights).