feat: make trace ID and span ID public on OtelData

[mladedav]

Motivation

Get the IDs from the OtelData struct.

Closes #227

Solution

When the context is started, we can get the IDs.

There is however nothing to report when the context is not yet fully built. But if it is not, there is not span ID to report and reporting the parent span's trace ID from the builder may not be correct as that may still change.

[mladedav]

cc @cschramm and @ollyswanson if you think this is good enough.

What wouldn't specifically work is something like

let span = tracing::debug_span!("root");
tracing::error!(parent: &span, " :( ");

while starting the span would work

let span = tracing::debug_span!("root");
let _guard = span.entered();
tracing::error!(" :) ");

[cschramm]

Works perfectly fine for my use case, where I use the dispatcher's current span (or rather its root span, by traversing the parents). If I'm not mistaken, that should always be entered.

[mladedav]

If I'm not mistaken, that should always be entered.

If you're talking about on_enter then yes, if you're talking about on_event, then no, see the first example of what would be broken if I understand what you mean.

But generally, people tend to use enter spans rather than explicitly setting the parent so you should be mostly fine.

[bantonsson]

Hey @mladedav I'm working on making it possible to get the context from the SpanRef instead of making the OtelData public again. I ran into this bug tokio-rs/tracing#3379, but I have a workaround for that. It would ensure that the context gets built when it is requested. I think that would be useful for other things like baggage.

[bantonsson]

If you disable the context_activation the context won't be created when you enter the span.

[mladedav]

Thanks, fixed.

[bantonsson]

I opened #234 as another solution

[mladedav]

For simplicity, I'd go with making it public again. We can deprecate this in the next version (and add the context activation-based approach in a point release whenever we want).