Replace standard encoding/json with goccy/go-json

[qasim-nylas]

Overview

This PR replaces the standard library encoding/json package with github.com/goccy/go-json in key performance-sensitive areas while maintaining compatibility with existing code. This change significantly improves JSON marshaling and unmarshaling performance.

Changes

• Added github.com/goccy/go-json as a dependency in go.mod
• Updated event/datacodec/json/data.go to use goccy/go-json
• Updated binding/format/format.go to use goccy/go-json
• Updated tests to accommodate the slightly different behavior of goccy/go-json
• Added benchmark tests to compare performance

Performance Improvements

JSON Marshal Performance

BenchmarkMarshal/encoding/json     17362054    340.0 ns/op    224 B/op    2 allocs/op
BenchmarkMarshal/jsoniter          18567894    330.5 ns/op    224 B/op    2 allocs/op
BenchmarkMarshal/goccy/go-json     30167839    202.0 ns/op    224 B/op    2 allocs/op

JSON Unmarshal Performance

BenchmarkUnmarshal/encoding/json    3158509    1917 ns/op     568 B/op   16 allocs/op
BenchmarkUnmarshal/jsoniter        11441949    523.5 ns/op    280 B/op    9 allocs/op
BenchmarkUnmarshal/goccy/go-json   14663540    399.2 ns/op    376 B/op    6 allocs/op

Summary of Improvements:

• Marshal: ~41% faster than standard library, ~39% faster than jsoniter
• Unmarshal: ~79% faster than standard library, ~24% faster than jsoniter

Notes

• This PR only replaces the standard library json implementation with goccy/go-json
• The existing jsoniter implementation in event_unmarshal.go is left untouched to avoid breaking changes
• Tests have been updated to accommodate the different error messages and behavior of goccy/go-json
• Future work could include transitioning more components to goccy/go-json for additional performance improvements

Testing

All tests in the v2 module pass successfully. The added benchmarks demonstrate significant performance improvements.

[embano1]

Hi, this comes somewhat out of the blue for me. Was this discussed in a meeting or is there an issue that I can read to understand why we are introducing another dependency? Do we have users complaining about performance issues with the existing encoders? Also, the Go community is moving to JSON v2 which also promised performance improvements with API compatibility - and without adding new dependencies which I'm not keen to add more to this project given its importance and reliance from many users and enterprises, unless strictly needed.

Our CONTRIBUTING guide describes the typical flow for this project: https://github.com/cloudevents/sdk-go/blob/main/CONTRIBUTING.md