subscriber: skip EnvFilter RwLock in span callbacks when no dynamic directives are configured

[kv-cache]

Motivation

EnvFilter maintains two RwLock-protected HashMaps (by_id and by_cs) for tracking per-span field-level match state. These are only populated when has_dynamics is true — i.e., when the filter includes span-name or field-level directives like my_crate[span_name]=debug.

However, the span lifecycle callbacks (on_new_span, on_enter, on_exit, on_close, on_record) unconditionally acquire the by_id read lock (or write lock for on_close) on every invocation, even when has_dynamics is false and the maps are guaranteed empty.

For the common case of pure target=level directives (e.g. RUST_LOG=info,hyper=warn), these locks are acquired and released on every span enter/exit/close/record with no effect.

Problem

Under high concurrency this causes measurable lock contention. A GDB backtrace captured from a Tokio-based HTTP server (80+ async workers, 3 EnvFilter instances as per-layer filters) during a load test showed ~25 threads contending on RwLock::read inside EnvFilter::on_enter, on_exit, and cares_about_span, with threads blocked in read_contended by on_close's write lock:

#0 std::sys::sync::rwlock::futex::RwLock::read_contended
#1 RwLock::read (self=0x55e0c7694178)
#2 RwLock<HashMap<SpanId, MatchSet<SpanMatch>>>::read
#3 EnvFilter::on_enter at filter/env/mod.rs:585

Solution

Add an early if !self.has_dynamics { return; } guard to each of the five span lifecycle methods. When dynamic directives are present, the existing code path runs unchanged. When they're absent (the common case), the lock is never touched.

[hds]

Thank you for submitting this PR!

Would it be possible to add regressions tests for this change?

Normally we run and avoid unit tests, but this might be a case where it's rhetorical only way to test.

Also, do you have any perf timings before and after the change? Is be interested to see them in the PR message or comments. Thanks!

[kv-cache]

Thanks! I had originally added 2 tests but they seemed redundant to existing tests. Let me take a look again.
Re perf: With this change I hope to not see those locks in cpu profiles again but I dont expect an explicit e2e gain from it - its more about mechanical sympathy on data paths. Maybe more visible with criterion benchmarks. I'll post an update.