Add APIs for getting the current logfire span

[dmontagu]

Addresses #674

This is a proposed implementation for how we can make it possible to get access to the current LogfireSpan, for making use of the various methods/etc. on it that aren't on the result of opentelemetry.trace.get_current_span() when you don't have access to the value.

The motivating use case for this is having access to methods of LogfireSpan inside functions instrumented with @logfire.instrument. Right now, there is no way to get access to the LogfireSpan, as opentelemetry.trace.get_current_span doesn't return that. This PR makes it so that logfire.current_logfire_span() returns the LogfireSpan if the current otel span corresponds to a LogfireSpan, and something API-compatible if it does not. (I also added logfire.current_span() as a more easily discovered re-export of opentelemetry.trace.get_current_span, don't necessarily need to keep that.)

---

Note that we've discussed making it so that when you call opentelemetry.trace.get_current_span() you get a LogfireSpan back, but the naive approach to this would have the consequence that spans created by other instrumentations would also end up being LogfireSpans, with the associated modified method behaviors/overhead/etc. This may be a good idea, but it's not immediately clear to me.

The good news is that the implementation in this PR would be backwards compatible if we were to make that change, and most of the logic brought in in this PR would just get removed, just the current_span and current_logfire_span functions would remain.

---

I haven't added any tests yet, mostly because I don't want to put in the effort if the approach is going to be rejected.

[adriangb]

I think we should use the existing OTEL APIs

[cloudflare-workers-and-pages]

Deploying logfire-docs with    Cloudflare Pages

Latest commit:	27f1424
Status:	✅  Deploy successful!
Preview URL:	https://afe037b0.logfire-docs.pages.dev
Branch Preview URL:	https://dmontagu-get-current-logfire.logfire-docs.pages.dev

View logs

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 99.91%. Comparing base (f0b2989) to head (27f1424).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
logfire/current_span.py	69.23%	7 Missing and 1 partial ⚠️
logfire/_internal/main.py	83.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##              main     #675      +/-   ##
===========================================
- Coverage   100.00%   99.91%   -0.09%     
===========================================
  Files          137      138       +1     
  Lines        10750    10793      +43     
  Branches      1473     1475       +2     
===========================================
+ Hits         10750    10784      +34     
- Misses           0        7       +7     
- Partials         0        2       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[samuelcolvin]

I would suggest we add just current_logfire_span, but perhaps for consistency it should be called get_current_logfire_span?

Is there a noticeable memory or CPU overhead? I assume not, but we should perhaps do some basic checks.

Let's see what @alexmojaki says, but I'm strongly in favour of moving quickly, even if it's with an imperfect solution.

[samuelcolvin]

are we sure this should be public.

[samuelcolvin]

I think it could be confusing or cause weird side effects that the imported current_span overrides the current_span module.