prevent panics when used with per-layer filters

[guswynn]

Motivation

Currently, if the tracing-opentelemetry Layer has a per-layer filter (in these examples, ones that allow only >=DEBUG) the following two cases behave differently:

let root = tracing::trace_span!("root");
tracing::debug_span!(parent: &root, "child");

let root = tracing::trace_span!("root");
oot.in_scope(|| tracing::debug_span!("child"));

The former panics, and the latter successfully creates a single-span trace. Note that this ONLY happens if there is another layer interested in the TRACE level (otherwise, the tracing current-level-filter fast-path filters the root spans out at their callsites).

This may seem rare, but it becomes more common when the per-layer filter is a reload filter, which means the parent and child spans can be differently filtered if the filter is reloaded between their creation (example: https://github.com/MaterializeInc/database-issues/issues/4358)

Solution

Handle this case gracefully. I also did the same in on_follows_from

[guswynn]

Its unclear to me if this also needs to be if let Some...my understanding is that if Context::span returned span data for the follows span, then this lay did in fact see the follows span and added this data in on_new_span. This would mean that the parent_context function could also .expect getting the OtelData from the parent span, but Im not sure...

[jtescher]

I am not aware of cases where the contextual spans would not have their data in the registry so I think you are correct here that it's ok.

[davidbarsky]

I think this change makes sense, especially since the only behavioral change is "don't panic".

[jtescher]

Looks good, thanks @guswynn, sorry about the delay

[jtescher]

I am not aware of cases where the contextual spans would not have their data in the registry so I think you are correct here that it's ok.

[guswynn]

@jtescher thanks for the review!