fix: guard TelemetryEventBuffer against re-entrant mutex acquisition

[sentry-junior]

Problem

MetricEventBuffer (and LogEventBuffer) use a non-reentrant Mutex. When transport instrumentation calls Sentry.metrics.* from inside send_items — while the mutex is already held — the same thread tries to acquire it again, raising:

ThreadError: deadlock; recursive locking

The re-entrant call can come from any code that fires during an outgoing HTTP request:

• Yabeda HTTP instrumentation (yabeda-http_requests, yabeda-rails)
• Custom transports that call Sentry.metrics.* during send_data (see getsentry/repro#46)
• Any other transport-layer hook emitting Sentry metrics

The repeated deadlock prevents the buffer from draining, causing the steady memory growth reported in #2963.

Fix — @mutex.owned? guard in TelemetryEventBuffer

A single guard in the base class protects all buffers (metrics, logs) against all re-entrant callers, regardless of origin:

def add_item(item)
  return self if @mutex.owned?
  @mutex.synchronize { ... }
end

def flush
  return self if @mutex.owned?
  @mutex.synchronize { ... }
end

Mutex#owned? returns true only when the same thread already holds the lock — the exact condition that would deadlock. Items from re-entrant calls are silently dropped. Normal concurrent access from other threads is unaffected (they block on synchronize as before).

Both add_item and flush are guarded because both acquire @mutex and call send_items.

Why not also guard at the integration layer?

An earlier iteration added a thread-local flag in HTTPTransport (sending?) and checks in Sentry::Yabeda::Adapter to skip metric forwarding during transport sends. This was removed because:

• The @mutex.owned? guard is sufficient — it catches the deadlock at the exact point it would occur
• The thread-local flag added cross-gem coupling (transport internals leaked into the Yabeda adapter)
• The outer filter only saved trivial work (a string join + method call that hits the guard and returns)
• A general fix in the base class is more reliable than per-integration opt-outs

Call chain (with fix applied)

MetricEventBuffer#flush / #add_item
  @mutex.synchronize  ← thread acquires mutex
    send_items
      Client#send_envelope → HTTPTransport#send_data
        Net::HTTP POST
          → instrumentation fires (yabeda / custom / any)
            → Sentry.metrics.*
              → MetricEventBuffer#add_item
                  return self if @mutex.owned?  ← drops safely, no deadlock

Changes

File	Change
sentry-ruby/lib/sentry/telemetry_event_buffer.rb	@mutex.owned? guard in add_item and flush
sentry-ruby/spec/support/shared_examples_for_telemetry_event_buffers.rb	Re-entrancy specs (no deadlock, silent drop)

Fixes #2963
Refs getsentry/repro#46