feat!: remove enable_logs/metrics

[jpnurmi]

Important

BREAKING CHANGE

Remove sentry_options_get/set_enable_logs and sentry_options_get/set_enable_metrics

Structured logs and metrics have been enabled by default since 0.13.

We recognize that this change may inconvenience applications that rely on the opt-out. Use sentry_options_set_before_send_log or sentry_options_set_before_send_metric to filter logs or metrics. We made this tradeoff deliberately because consistent behavior across SDK integrations will help most users successfully adopt these features.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6522a1f. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.22%. Comparing base (aaf2432) to head (4eabf1e).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1980   +/-   ##
=======================================
  Coverage   74.22%   74.22%           
=======================================
  Files         104      104           
  Lines       25361    25340   -21     
  Branches     4534     4527    -7     
=======================================
- Hits        18824    18809   -15     
+ Misses       5237     5232    -5     
+ Partials     1300     1299    -1     

🚀 New features to boost your workflow:

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

[limbonaut]

Consensus changed towards making enable_logs noop, and removing it in the next major. Although, from compile-time safety perspective, it's less important for native.

[JoshuaMoelans]

one of my only concerns here is starting the batcher threads for every SDK user now, even if they never call a single log/metric API. but think there's probably no real way around this 🤔

[jpnurmi]

Yeah, these unconditional threads are a bit annoying, but fortunately quite cheap because they don't do anything besides waiting on the condition variable.

Perhaps lazy batcher creation/start could be one option? It might introduce some latency for the first log/metric call, but it would be justified because it speeds up SDK init for everyone, and moves the cost for those who actually use logs and metrics...

[JoshuaMoelans]

I had a prototype of this approach in #1611 that we ended up not doing back then, but might be worth reconsidering 👀

[JoshuaMoelans]

I created a follow-up docs PR getsentry/sentry-docs#19041 , to be merged after we release this one