fix: Remove initial-exec TLS storage to enable dlopen

[r1viollet]

What does this PR do?

This is a revert of the following PR in favour of changes proposed here.

Fixes the failure reported in #520 / #521: libdd_profiling.so fails to load its embedded .so when opened via dlopen.
Musl hard-rejects initial-exec TLS cross-library references when the defining library is dynamically loaded (ldso/dynlink.c:456: tls_id > static_tls_cnt), regardless of symbol visibility.

Motivation

Allowing dlopen use case.

How

Replace direct initial-exec TLS storage of TrackerThreadLocalState with pthread_key_t + pthread_getspecific/pthread_setspecific:

• AllocationTracker::_tl_state_key is an std::atomic<pthread_key_t>, initialized to a sentinel kInvalidKey
• ensure_key_initialized() creates the key once via CAS — called from allocation_tracking_init()
• get_tl_state() is now a single pthread_getspecific call with no initialized flag check (null pointer is the sentinel)
• init_tl_state() heap-allocates the state and registers it with pthread_setspecific; the destructor is called automatically on thread exit

This eliminates the cross-library TLS reference entirely, so the embedded .so no longer requires any symbol from the loader at load time. The RTLD_NOLOAD self-promotion mechanism (which also used dladdr, unavailable in the -nolibc universal build) is removed as dead code.

How to test the change?

A new test loader_rtld_global loads libdd_profiling.so via dlopen(..., RTLD_GLOBAL) and calls ddprof_start_profiling(). Without the fix it returns -1 (embedded library not loaded). With the fix it passes on both glibc (Ubuntu 24.04) and musl (Alpine 3.22).

Performance

Claude measured before and after accessing TLS state
Benchmark results: pthread_getspecific (branch) vs __thread initial-exec (main)

  ┌────────────────────────┬───────────────────────────────────────────┬─────────┬─────────┬───────────────────────────────┐                                                                                
  │       Benchmark        │         What one iteration covers         │  main   │ branch  │        Per-call delta         │
  ├────────────────────────┼───────────────────────────────────────────┼─────────┼─────────┼───────────────────────────────┤                                                                                
  │ BM_GetTlState          │ 4 threads × 10k get_tl_state() calls      │ 10.3 µs │ 27.1 µs │ +1.7 ns/call                  │
  ├────────────────────────┼───────────────────────────────────────────┼─────────┼─────────┼───────────────────────────────┤
  │ BM_ShortLived_Tracking │ 4 short-lived threads × 2k alloc/free ops │ 208 µs  │ 220 µs  │ ~1.5 ns/call (consistent)     │                                                                                
  ├────────────────────────┼───────────────────────────────────────────┼─────────┼─────────┼───────────────────────────────┤                                                                                
  │ BM_LongLived_Tracking  │ 4 persistent threads × 2k alloc/free ops  │ 315 µs  │ 315 µs  │ 0 (TLS lost in sampling work) │                                                                                
  └────────────────────────┴───────────────────────────────────────────┴─────────┴─────────┴───────────────────────────────┘                                                                                

So the TLS access is slower. Considering this is still O(nanoseconds) in the hot path, I hope this does not impact performance significantly.

[r1viollet]

WIP: Still some alpine / glibc differences to consider

[r1viollet]

There is an issue with the initial-exec + musl dlopen that needs a bigger change

[pr-commenter]

Benchmark results for collatz

Parameters

	Baseline	Candidate
config	baseline	candidate
profiler-version	ddprof 0.24.0+bf23f795.103772975	ddprof 0.24.0+e8caf60b.104153116

Summary

Found 0 performance improvements and 0 performance regressions! Performance is the same for 1 metrics, 0 unstable metrics.

See unchanged results

scenario	Δ mean execution_time
scenario:ddprof -S bench-collatz --preset cpu_only collatz_runner.sh	same

[pr-commenter]

Benchmark results for BadBoggleSolver_run

Parameters

	Baseline	Candidate
config	baseline	candidate
profiler-version	ddprof 0.24.0+bf23f795.103772975	ddprof 0.24.0+e8caf60b.104153116

Summary

Found 0 performance improvements and 0 performance regressions! Performance is the same for 1 metrics, 0 unstable metrics.

See unchanged results

scenario	Δ mean execution_time
scenario:ddprof -S bench-bad-boggle-solver BadBoggleSolver_run work 1000	same