feat: add (u)int64 sentry_value_t type

[JoshuaMoelans]

only the new commits added after previous PR was merged

---

Extracted from #1301 as this is relevant not only to Logs, but also for the read/capture envelopes feature (see comment). We can merge this to main before logs is finished.

The feature is mostly done already, but needs some more testing (e.g. seeing if values end up in the UI)

Also this needs to be tackled:

Looks like sentry__value_from_json also needs some changes to avoid sentry__strtod_c and be able to handle > 2^53.

TODO

• testing SDK->UI
  -> need to send uint64 as strings (see Logs spec)
• sentry__value_from_json for (u)int64
• update docs; wherever we mention what types native supports, the (u)int64 type should now also be mentioned fix(native): update sentry_value_t example with 64-bit integer types sentry-docs#14509
  • https://docs.sentry.io/platforms/native/tracing/instrumentation/custom-instrumentation/#improving-data-on-transactions-and-spans

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

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

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- add `(u)int64 sentry_value_t` type ([#1326](https://github.com/getsentry/sentry-native/pull/1326))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against 2fc0baa

[jpnurmi]

Regarding sentry__value_from_json, I'd try to avoid manual integer parsing (is_integer_string). I suppose we need to check for '-' to determine whether unsigned values are allowed but besides that, I'd only operate with strtoxxx together with the appropriate errno and range checks. Can we keep it closer to the original code and basically just add extra checks to the "else" branch where it previously had the double fallback? Also, would one strtoll or strtoull call be enough and then we'll do the cast manually based on the sign and range?

[jpnurmi]

what happened? what is this needed for? i was't part of the original reviews and might be missing some background context but i tried reverting "always send uint64 as string" and the unit tests pass. :)

[JoshuaMoelans]

Ah seems that I forgot to link to the develop docs; basically for Logs it is specified that we cannot ingest unsigned 64-bit integers yet (see this section), and I tried whether this is the case in general by trying to send some transactions with 64-bit unsigned integer data. Turns out we cannot handle this in the Sentry UI (yet), so for now I think it makes sense to send all uint64 values as strings instead.

In the Logs PR we just store the uint64 arguments as string sentry_value_t types, but with this more general change we could have logs store them as uint64, and then we only need to update thesentry__jsonwriter_write_uint64 function once these values can get handled.

Reverting this should make the value_uint64 test fail, since it expects "" around the numbers in the json representation.

---

To test the UI handling of these values, I added this in the example.c before sending a transaction:

        sentry_transaction_set_data(tx, "bigger", sentry_value_new_int32(INT64_MIN));
        sentry_transaction_set_data(tx, "biggest", sentry_value_new_uint64(UINT64_MAX));

And without the uint64->string conversion, the UI shows this:

Adding the conversion makes it show up correctly.

[JoshuaMoelans]

@sentry review

[jpnurmi]

LGTM 👍

Only minor changes after already having been thoroughly reviewed in #1301