ref: Make logs, metrics go via scope

[sentrivana]

Description

Logs and metrics were going through a completely separate pipeline compared to other events.

Conceptually, they're still different from regular events since they're more lightweight and attribute-based (no data, contexts, etc., everything is an attribute) so separate handling makes sense. However, the pipeline should still conceptually resemble the one we use for other event types, for consistency.

Current pipeline for non-log, non-metric events

• The top-level API calls scope.capture_XXX. This merges the current scope stack and calls client.capture_XXX with the resulting merged scope.
• client.capture_XXX contains virtually all of the logic, most notably:
  • It applies the scope to the event by calling scope.apply_to_event, populating contexts, user data, etc.
  • It serializes the event.
  • It constructs the final envelope and sends it to the transport.

This PR

• Instead of the logging/metrics functionality going straight to client.capture_XXX, we call scope.capture_XXX, like we do for other event types, and then call client.capture_XXX from there.
• Instead of inlining (and duplicating) all the attribute logic, client.capture_XXX now calls a new scope.apply_to_telemetry function internally (akin to scope.apply_to_event, but sets attributes instead).
• The rest of the pipeline was left as-is for now, so metrics and logs are directly put into the batcher which itself serializes them. It's questionable whether making this part of the pipeline more similar to the event one would be a good idea since in Span First it'll be beneficial to have unserialized telemetry in the buffer, as is the case now with logs and metrics.

Additionally:

• Unify attribute-related types
• Move duplicated format_attribute to utils

Note: This is just a first PR, I will refactor further.

Issues

Reminders

• Please add tests to validate your changes, and lint your code using tox -e linters.
• Add GH Issue ID & Linear ID (if applicable)
• PR title should use conventional commit style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[codecov]

Codecov Report

❌ Patch coverage is 82.55814% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.21%. Comparing base (2ce4379) to head (270be59).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
sentry_sdk/scope.py	80.30%	3 Missing and 10 partials ⚠️
sentry_sdk/client.py	86.66%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5213      +/-   ##
==========================================
- Coverage   84.25%   84.21%   -0.05%     
==========================================
  Files         181      181              
  Lines       18463    18469       +6     
  Branches     3288     3283       -5     
==========================================
- Hits        15556    15553       -3     
- Misses       1894     1900       +6     
- Partials     1013     1016       +3     

Files with missing lines	Coverage Δ
sentry_sdk/integrations/logging.py	87.58% <100.00%> (ø)
sentry_sdk/integrations/loguru.py	84.21% <100.00%> (ø)
sentry_sdk/logger.py	89.47% <100.00%> (-0.27%)	⬇️
sentry_sdk/metrics.py	100.00% <100.00%> (ø)
sentry_sdk/client.py	84.35% <86.66%> (+0.77%)	⬆️
sentry_sdk/scope.py	87.69% <80.30%> (-0.67%)	⬇️

... and 3 files with indirect coverage changes

[sentrivana]

This is now essentially a dispatcher on ty. Unfortunately we need the explicit type and can't look at the actual type of the thing coming in since it's all just dicts. I'll be exploring whether we can make this better without introducing breaking changes.