fix(tracing): avoid assigning span's local root to self, so that the python GC doesn't kick in [backport 2.14]

[github-actions]

Backport e160b36 from #10809 to 2.14.

<<Description copied from the original PR>>

We (Modal Labs) noticed that enabling tracing in parts of our code caused the Python GC to kick in a lot and add large delays to our event loop. A simple repro (see test) showed us that there was a self reference cycle in span when a top-level span's local root was assigned to the span itself, preventing Python from cleaning up the objects by reference counting.

The change itself is pretty straightforward - we use None to represent when a span's local root is itself. The span still exposes _local_root with the same behavior via a property, and internally stores a _local_root_value that holds a non-self-referential span. This also means that the tracer no longer needs to explicitly set the local root for top-level spans. This should be fairly non-risky as it doesn't change any code behavior.

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[datadog-dd-trace-py-rkomorn]

Datadog Report

Branch report: backport-10809-to-2.14
Commit report: 49207aa
Test service: dd-trace-py

✅ 0 Failed, 1286 Passed, 0 Skipped, 36m 36.28s Total duration (54.72s time saved)

[github-actions]

CODEOWNERS have been resolved as:

releasenotes/notes/fix-span-unnecessary-gc.yaml                         @DataDog/apm-python
ddtrace/_trace/span.py                                                  @DataDog/apm-sdk-api-python
ddtrace/_trace/tracer.py                                                @DataDog/apm-sdk-api-python
ddtrace/propagation/http.py                                             @DataDog/apm-sdk-api-python
tests/tracer/test_tracer.py                                             @DataDog/apm-sdk-api-python

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-09-26 19:33:57

Comparing candidate commit 49207aa in PR branch backport-10809-to-2.14 with baseline commit 467db5a in branch 2.14.

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

scenario:otelspan-add-metrics

• 🟩 max_rss_usage [-10.189MB; -9.985MB] or [-28.208%; -27.643%]

scenario:otelspan-add-tags

• 🟩 max_rss_usage [-9.166MB; -8.946MB] or [-26.098%; -25.472%]

scenario:span-add-metrics

• 🟩 max_rss_usage [-18.189MB; -17.968MB] or [-37.127%; -36.676%]

scenario:span-add-tags

• 🟩 max_rss_usage [-4.399MB; -4.192MB] or [-15.282%; -14.565%]

scenario:span-start

• 🟩 execution_time [-2.431ms; -2.046ms] or [-12.138%; -10.218%]

scenario:span-start-traceid128

• 🟩 execution_time [-2.434ms; -2.018ms] or [-11.968%; -9.921%]