fix: reset client report counters during initialization

[tustanivsky]

This PR fixes a bug where the global g_discard_counts array in the client report system is not reset between
sentry_close() / sentry_init() cycles. As a result, discard counts from a previous SDK session leak into the next
one within the same process.

This causes the client_report_concurrent unit test to fail on platforms that run all tests in a single process (e.g.
Xbox, where process forking is unavailable). A prior test leaves one residual discard count, causing the concurrent
test to observe 80,001 instead of the expected 80,000 (failing Xbox CI run example).

The fix introduces sentry__client_report_reset() and calls it at the start of sentry_init(), ensuring that each SDK
initialization begins with a clean state. This is also semantically correct for production: applications that
re-initialize the SDK within a single process should not carry over stale discard counts into a new session.

Related items:

• feat: client reports #1549

[jpnurmi]

This is also semantically correct for production: applications that re-initialize the SDK within a single process should not carry over stale discard counts into a new session.

I went a bit back and forth with the init-time reset. I ended up leaving it out because as far as I know, client reports are not associated with sessions, so carrying over the counts felt like the right behavior. I don't have a strong opinion on this, but perhaps fixing the concurrent test could be an alternative option?

• feat: client reports #1549 (comment)

[jpnurmi]

Wouldn't it be the correct behavior to reset the counters at the beginning of test_client_report_concurrent since the test assumes/requires a clean state, instead of throwing away counts in production? The test could either call sentry__client_report_reset or sentry__client_report_save() with a temp throwaway report to drain the counters.

[tustanivsky]

Even though client reports aren’t technically tied to sessions, I'd say that carrying them over into a new SDK lifecycle feels somewhat misleading compared to simply dropping them (which as I understand from https://develop.sentry.dev/sdk/telemetry/client-reports/#core-operation is acceptable).

We could fix this in the test itself but wouldn't that mean individual tests depend on that implicit global state shared across SDK sessions? Adding new tests or simply reordering existing ones could break things again.

[jpnurmi]

I think either way makes sense. :) @supervacuus do you have any preference?

[supervacuus]

I think either way makes sense. :) @supervacuus do you have any preference?

Nope, not really. As always, when specs are unclear, I would look at how a sample of other SDKs is doing it.