chore(asm): clean libddwaf loading

[christophe-papazian]

Depending of the timing, libddwaf loading process could create triggers that would create loops in our instrumentation.
From what I investigated:

• if loaded too early, it could have bad interactions with gevent.
• if loaded too late, it could be self instrumented by the tracer, creating a loop, as ctypes is using Popen and subprocess.

while keeping the late loading introduced by 2 previous PRs

• chore(asm): improve dependency for api security #11987
• ci(appsec): fix ddwaf circular import #12013
  this PR introduced a mechanism to bypass tracer instrumentation during ctypes loading, to avoid a possible loop that would prevent the WAF to be loaded.

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/appsec/_ddwaf/ddwaf_types.py                                    @DataDog/asm-python
ddtrace/appsec/_processor.py                                            @DataDog/asm-python
ddtrace/contrib/internal/subprocess/patch.py                            @DataDog/asm-python
ddtrace/settings/asm.py                                                 @DataDog/asm-python

[datadog-dd-trace-py-rkomorn]

Datadog Report

Branch report: christophe-papazian/clean_waf_import
Commit report: 11177a0
Test service: dd-trace-py

✅ 0 Failed, 130 Passed, 1378 Skipped, 4m 49.66s Total duration (35m 5.88s time saved)

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-01-28 16:26:51

Comparing candidate commit 11177a0 in PR branch christophe-papazian/clean_waf_import with baseline commit 16d5280 in branch main.

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

[gnufede]

Should we backport this to 2.20 (and maybe previous releases?)

[github-actions]

The backport to 2.19 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.19 2.19
# Navigate to the new working tree
cd .worktrees/backport-2.19
# Create a new branch
git switch --create backport-12102-to-2.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 4f0bcb5a59378fb6015230f9f9ad04199fc380b5
# Push it to GitHub
git push --set-upstream origin backport-12102-to-2.19
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.19

Then, create a pull request where the base branch is 2.19 and the compare/head branch is backport-12102-to-2.19.