chore(build): consolidate libdatadog symbols in lib_native

[hoolioh]

Both profiling and src/native depend on libdatadog, but slightly different manner prior to this PR.

• Profiling consumed statically built libdatadog libraries
• src/native Rust crate simply added libdatadog crates as dependencies

This PR makes sure that we build libdatadog dependency as part of src/native and export profiling ffi symbols there.

Regarding benchmark SLOs:

• Mostly increasing max_rss_usage. Looks ok and acceptable to @taegyunkim. We're changing the way we build and consume libdatadog dependency.

PROF-12235

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:

build_libnative.py                                                      @DataDog/apm-core-python
ddtrace/internal/datadog/profiling/cmake/FindLibNative.cmake            @DataDog/profiling-python
ddtrace/internal/datadog/profiling/crashtracker/python_runtime_stub.c   @DataDog/profiling-python
src/native/.cargo/config.toml                                           @DataDog/apm-core-python
.github/workflows/build_deploy.yml                                      @DataDog/python-guild @DataDog/apm-core-python
.github/workflows/build_python_3.yml                                    @DataDog/python-guild @DataDog/apm-core-python
.github/workflows/system-tests.yml                                      @DataDog/python-guild @DataDog/apm-core-python
.gitlab/benchmarks/bp-runner.microbenchmarks.fail-on-breach.yml         @DataDog/python-guild @DataDog/apm-core-python
ddtrace/appsec/_iast/_taint_tracking/CMakeLists.txt                     @DataDog/asm-python
ddtrace/internal/datadog/profiling/build_standalone.sh                  @DataDog/profiling-python
ddtrace/internal/datadog/profiling/crashtracker/CMakeLists.txt          @DataDog/profiling-python
ddtrace/internal/datadog/profiling/dd_wrapper/CMakeLists.txt            @DataDog/profiling-python
ddtrace/internal/datadog/profiling/dd_wrapper/test/CMakeLists.txt       @DataDog/profiling-python
ddtrace/internal/datadog/profiling/ddup/CMakeLists.txt                  @DataDog/profiling-python
pyproject.toml                                                          @DataDog/python-guild
setup.py                                                                @DataDog/python-guild
src/native/Cargo.lock                                                   @DataDog/apm-core-python
src/native/Cargo.toml                                                   @DataDog/apm-core-python
src/native/lib.rs                                                       @DataDog/apm-core-python

[github-actions]

Bootstrap import analysis

Comparison of import times between this PR and base.

Summary

The average import time from this PR is: 278 ± 2 ms.

The average import time from base is: 280 ± 3 ms.

The import time difference between this PR and base is: -2.2 ± 0.1 ms.

Import time breakdown

The following import paths have grown:

ddtrace.auto 0.293 ms (0.11%)

ddtrace 0.293 ms (0.11%)

ddtrace._logger 0.293 ms (0.11%)

ddtrace.internal.telemetry 0.293 ms (0.11%)

ddtrace.settings._agent 0.293 ms (0.11%)

ddtrace.settings._core 0.293 ms (0.11%)

ddtrace.internal.native 0.293 ms (0.11%)

ddtrace.internal.native._native 0.293 ms (0.11%)

The following import paths have shrunk:

ddtrace.auto 2.358 ms (0.85%)

ddtrace.bootstrap.sitecustomize 1.680 ms (0.60%)

ddtrace.bootstrap.preload 1.680 ms (0.60%)

ddtrace.internal.remoteconfig.client 0.661 ms (0.24%)

ddtrace.settings.crashtracker 0.290 ms (0.10%)

ddtrace.internal.datadog.profiling.crashtracker 0.290 ms (0.10%)

ddtrace.internal.datadog.profiling.crashtracker._crashtracker 0.290 ms (0.10%)

ddtrace 0.678 ms (0.24%)

ddtrace.internal._unpatched 0.030 ms (0.01%)

json 0.030 ms (0.01%)

json.decoder 0.030 ms (0.01%)

re 0.030 ms (0.01%)

enum 0.030 ms (0.01%)

types 0.030 ms (0.01%)

[taegyunkim]

I've been seeing a very weird issue where _crashtracker.so is linked to a _native.so file with wrong python version. This was due to the fact that 1) we run build in same directory for all different versions and 2) libdd_wrapper.so didn't have different names for different python versions, and same libdd_wrapper.so was used for all different versions of Python and 3) _crashtracker.so -> libdd_wrapper.so->_native.so` this .so dependency chain.

Before this PR it was ok for libdd_wrapper.so to not be compiled differently for different versions of Python because it didn't reference any of Python symbols. However, with this PR, since it started to depend on _native.so, now it has to.

There are few other things that I discovered while debugging this PR

• chore(build, profiling): fix extension hash computation for profiling modules #14191
• chore(build): use different extension cache venv for each python version #14201
• chore(build): fix extension module hash calculation #14195
• We can speed up build_base_venv job runtime by using different CARGO_TARGET_DIR for each versions of Python, as cargo lock prevents from running build for multiple build_base_venv jobs at the same time in the same directory. 8e79eb6 I reverted this commit in this PR to minimize diff. I'll follow up with a separate PR.