feat: bidirectional JSON & MessagePack (de)serialization

[jpnurmi]

Expose sentry_value_from_json, sentry_value_from_msgpack, and sentry_value_from_msgpack_stream alongside the existing serializers to provide public bidirectional APIs for reading and writing sentry values as JSON and MessagePack. Promote sentry_value_to_msgpack from experimental to stable.

Ref: #2116

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 0c019ca

[codecov]

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 75.34%. Comparing base (3d564a0) to head (0c019ca).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2153      +/-   ##
==========================================
- Coverage   75.40%   75.34%   -0.07%     
==========================================
  Files         103      103              
  Lines       28105    28102       -3     
  Branches     5133     5132       -1     
==========================================
- Hits        21193    21173      -20     
- Misses       5577     5602      +25     
+ Partials     1335     1327       -8     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[limbonaut]

Any idea why it was public in the first place?
PS: I tried to find any public consumer on GH, but there seems to be none, bar some declaration in a testing file that seems to be unused.

[jpnurmi]

Both JSON and MessagePack serialization were originally made available side by side in c082e7d.

Hard to say what the motivation for MessagePack was back then, but one potential could've been sentry-contrib-native, some old unofficial Rust bindings with familiar contributors, where sentry_value_to_msgpack was used for native-to-Rust object conversion: https://github.com/daxpedda/sentry-contrib-native/blob/a12d0d41129914fd7fc519d177d20d040e47bf2d/src/value.rs#L96-L113

I don't have super strong feelings about public MessagePack (de)serialization. Doing the opposite and hiding the still-experimental function from the public API could also be a fine alternative. On the other hand, MessagePack would be superior to JSON when doing sentry_value_t object/map conversions in downstream SDKs. 🤔

[limbonaut]

On the other hand, MessagePack would be superior to JSON when doing sentry_value_t object/map conversions in downstream SDKs.

Only if you are lazy 😄 Since we've got foreach, I bet it would be faster to just write a little converter function. Maybe nice to have for Android, though.

[limbonaut]

This may be useful for Android scope sync, but currently unused.

I wonder if it makes some sense to put such APIs that are only used by downstream/hybrid SDKs into a separate header? Say include/sentry_internal.h. Just to keep user-facing header less bulky.

[jpnurmi]

sentry.h is currently 4433 lines and keeps growing fast. 😢 I've been wondering if it would make sense to either make it a proxy header that includes other sentry_xxx.h headers, or use some amalgamation script to generate it.

[jpnurmi]

I missed that even sentry_value_from_json wasn't public either, just exported. 🤯 Aren't serialization and deserialization basic needs? Would it go too far if we provided public, bidirectional APIs for both JSON and MessagePack? JSON is everywhere, and MessagePack has its advantages.

[limbonaut]

I agree. A lot of SDKs support serialization/deserialization, the JSON at least.