chore(deps): update Native SDK to v0.10.0

[github-actions]

Bumps modules/sentry-native from 0.9.1 to 0.10.0.

Auto-generated by a dependency updater.

Changelog

0.10.0

Breaking changes:

• By using transactions as automatic trace boundaries, transactions will, by default, no longer be part of the same singular trace. This is not the case when setting trace boundaries explicitly (sentry_regenerate_trace() or sentry_set_trace()), which turns off the automatic management of trace boundaries. (#1270)
• Change transaction sampling to be trace-based. This does not affect you when transactions are used for automatic trace boundaries (as described above), since every transaction is part of a new trace. However, if you manage trace boundaries manually (using sentry_regenerate_trace()) or run the Native SDK inside a downstream SDK like the Unity SDK, where these SDKs will manage the trace boundaries, for a given traces_sample_rate, either all transactions in a trace get sampled or none do with probability equal to that sample rate. (#1254)
• Moved Xbox toolchains to an Xbox-specific repository sentry-xbox. You can request access to the repository by following the instructions in Xbox documentation. (#1329)

Features:

• Add sentry_clear_attachments() to allow clearing all previously added attachments in the global scope. (#1290)
• Automatically set trace boundaries with every transaction. (#1270)
• Provide sentry_regenerate_trace() to allow users to set manual trace boundaries. (#1293)
• Add Dynamic Sampling Context (DSC) to events. (#1254)
• Add sentry_value_new_feedback and sentry_capture_feedback to allow capturing User Feedback. (#1304)
  • Deprecate sentry_value_new_user_feedback and sentry_capture_user_feedback in favor of the new API.
• Add sentry_envelope_read_from_file, sentry_envelope_get_header, and sentry_capture_envelope. (#1320)
• Add (u)int64 sentry_value_t type. (#1326)

Meta:

• Marked deprecated functions with SENTRY_DEPRECATED(msg). (#1308)

Internal:

• Crash events from Crashpad now have event_id defined similarly to other backends. This makes it possible to associate feedback at the time of crash. (#1319)

[Flash0ver]

question: Are the Breaking Changes in the Native SDK observable from the .NET SDK?

[jamescrosswell]

Reading through the change logs, it looks like the "breaking" changes are using sample_rand, adding a DSC to transactions/errors and Tracing without Performance. These are all supported by the .NET SDK already and implemented per the spec... so the two SDKs should play nicely together if one is an upstream and the other is a downstream (they've implemented the same protocol around propagating trace context via request headers).

From what I can tell, those changes aren't relevant in scenarios where the .NET SDK wraps the Native SDK (e.g. capturing native crash reports when .NET applications are compiled AOT or marshalling calls to functionality implemented in native dlls).

@supervacuus / @JoshuaMoelans can you confirm I've understood the above correctly?

[supervacuus]

Let's quickly go through the breaking changes and translate the effects for .NET SDK users:

• The first is only "breaking" in the sense that if you relied on all transactions to be part of the same trace before, this is no longer the case by default. However, since the .NET SDK manages the trace life-cycle of the Native SDK via sentry_set_trace() anyway, there is no apparent change for .NET SDK users, because in that configuration transactions do not act as trace boundaries.
• The second is the standard behavior for sample_rand, which wasn't implemented yet, but now is in effect due to the dynamic sampling context implementation. .NET SDK users will see the impact of this change, meaning trace-based sample_rand decisions will apply to either all transactions in that trace or none, but that is by design so that the trace's contents aren't artificially cut.
• The third means that the Native SDK is no longer buildable from the OSS repo alone (except if you provide your own CMake toolchain configuration). I am not up-to-date with the .NET SDK usage on Xbox, but I guess not yet, right @bruno-garcia?

So, the only "breaking" change that affects .NET SDK users (except for the Xbox change, let's wait for @bruno-garcia to chime in) is the second one. I leave it up to you whether this is even a breaking change for your users, since this was meant as more of an improvement for downstream SDK users. However, in our context, for a small percentage of users, it would be a breaking change.