chore(crashtracking): add python version to crashtracker tags

[sanchda]

During escalations it's currently difficult to find the exact Python version relevant for a defect. This is a simple fix for that.

I'm recommending a backport because

1. The fix is simple
2. 2.11 and onward introduce crashtracker, and we're still dealing with crashes from those versions

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

[github-actions]

CODEOWNERS have been resolved as:

ddtrace/internal/core/crashtracking.py                                  @DataDog/apm-core-python

[brettlangdon]

lgtm

this will also include any beta suffixes as well, e.g. 3.13.0b3+ is that ok with the spec for runtime version? (I'd like to keep it if we can)

[datadog-dd-trace-py-rkomorn]

Datadog Report

Branch report: sanchda/add_pyversion_to_crashtracker
Commit report: d4a091c
Test service: dd-trace-py

✅ 0 Failed, 1004 Passed, 282 Skipped, 28m 2.94s Total duration (8m 40.16s time saved)

[sanchda]

this will also include any beta suffixes as well, e.g. 3.13.0b3+ is that ok with the spec for runtime version? (I'd like to keep it if we can)

My take is that higher-level processing pipelines can normalize an overly-verbose version name in a runtime-aware way if they need to, but that our responsibility at the data collection level is to provide a fully qualified version string, identifying as precisely as possible the origin of the runtime build.

In future PRs, I'll be doing things like hashing libpython.so and other runtime assets during a crash, so that during investigation we can immediately qualify whether we're looking at the same thing a given user was utilizing at time of crash.

In my ideal dream state, our backend systems will actually have a roster of CPython/libc assets available for crash- or query-time analysis. But that's a dream. Or a nightmare I guess depending 🤷

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-09-19 20:41:40

Comparing candidate commit d4a091c in PR branch sanchda/add_pyversion_to_crashtracker with baseline commit 9922df5 in branch main.

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

scenario:iast_aspects-aspect_iast_do_encode

• 🟩 max_rss_usage [-2.693MB; -2.384MB] or [-9.039%; -8.003%]

scenario:iast_aspects-aspect_iast_do_join

• 🟩 max_rss_usage [-2.613MB; -2.368MB] or [-8.763%; -7.942%]