feat: allow custom json encoder/decoder.

[jmcarp]

The encoding/json package in the standard library isn't particularly performant, and there have been many first-party and third-party efforts to improve it. This patch allows users of the sdk to configure a custom json codec to marshall and unmarshall json with their tools of choice. Note: we can update to encoding/json/v2 as the default once it's marked stable in a future golang release.

For context, I started thinking about this because we wind up unmarshalling fairly large json payloads in the Oxide otel receiver. The resource/performance improvement from switching to a faster json library turned out to be small, but I thought I would check this in anyway—I'll take performance improvements even if small, and this may prove helpful for users making large volumes of requests through the sdk.

[lgfa29]

LGTM, provided the extra interface doesn't cause a performance hit in the default case. I don't think it would, but it may be worth adding a benchmark just to double-check.

I may also be worth documenting this option, and maybe provide an example or two of how to use an alternative encoder.

[sudomateo]

I don't oppose this change, but I will say that Go currently is experimenting with a json/v2 package: https://go.dev/blog/jsonv2-exp

They claim the following.

The Marshal performance of v2 is roughly at parity with v1. Sometimes it is slightly faster, but other times it is slightly slower. The Unmarshal performance of v2 is significantly faster than v1, with benchmarks demonstrating improvements of up to 10x.

I'm okay with deferring until Go 1.26 is released to see if they promote json/v2 to stable or merging this now if there's a need to swap the json encoder/decoder.

[jmcarp]

Yep, I noted the upcoming json improvements in the standard library in the commit message, but I take your point. I don't think the performance improvements from this change justify the extra work when we can just upgrade to json/v2 hopefully next year. Closing.