appsec: remove "appsec" build tag requirement

[RomainMuller]

What does this PR do?

Removes the appsec build tag. The in-app WAF can be disabled using a build-tag defined by the github.com/DataDog/go-libddwaf library (making it a no-op implementation). This build tag named datadog.no_waf has been made to obtain the same result than before but this makes appsec build requirements (which does not include cgo anymore) opt-out instead of opt-in.

AppSec still is disabled by default, and can be enabled with remote activation or DD_APPSEC_ENABLED=true.

Motivation

This makes ASM available in all builds by default, while still allowing an opt-out of code-level support when necessary. ASM support can be enabled by default as it no longer requires cgo to build.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.

For Datadog employees:

• If this PR touches code that handles credentials of any kind, such as Datadog API keys, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.

Unsure? Have a question? Request a review!

[pr-commenter]

Benchmarks

Benchmark execution time: 2023-11-22 13:10:48

Comparing candidate commit 382e61c in PR branch romain.marcadier/build-tag/APPSEC-9332 with baseline commit c418382 in branch main.

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

scenario:BenchmarkOTelApiWithCustomTags/datadog_otel_api-24

• 🟩 execution_time [-212.868ns; -141.532ns] or [-4.148%; -2.758%]

scenario:BenchmarkOTelApiWithCustomTags/otel_api-24

• 🟩 execution_time [-292.126ns; -190.874ns] or [-3.898%; -2.547%]

scenario:BenchmarkPartialFlushing/Enabled-24

• 🟥 execution_time [+5.761ms; +10.327ms] or [+2.045%; +3.666%]

scenario:BenchmarkSingleSpanRetention/no-rules-24

• 🟥 execution_time [+10.676µs; +13.423µs] or [+4.348%; +5.466%]

scenario:BenchmarkSingleSpanRetention/with-rules/match-all-24

• 🟥 execution_time [+11.510µs; +13.927µs] or [+4.657%; +5.635%]

scenario:BenchmarkSingleSpanRetention/with-rules/match-half-24

• 🟥 execution_time [+10.466µs; +13.049µs] or [+4.229%; +5.273%]

scenario:BenchmarkStartSpan-24

• 🟥 execution_time [+87.450ns; +128.750ns] or [+3.753%; +5.526%]

scenario:BenchmarkTracerAddSpans-24

• 🟥 execution_time [+93.382ns; +143.418ns] or [+2.325%; +3.570%]

[Julio-Guerra]

Thanks for bootstrapping this.

Strong opinion here: I don't want asm to be used instead of appsec anywhere in the engineering side of things, and especially in the software code/doc/tools, due to how ambiguous this is in the software world (actually it's not: it means assembly and nothing else ;-p).

appsec is clearer for readers (well known short name in the sec world as opposed to ASM which is a Datadog product idea to mimic APM to try to create/influence a new sec category), better referencing, aligned with DD_APPSEC_*, etc.

PS: I wasn't part of the renaming of all our GH teams into asm-* (they did it during my PTO and I'd have blocked it for the same reasons).

[nsrip-dd]

I don't see any profiling-related changes. go.mod + CI stuff looks good to me. Please ping if you need a re-review.

[knusbaum]

Great news!

[eliottness]

After investigating the performance loss it does not seem to be related to this PR because we are able to get back to usual performances level by removing this commit on main from our history. We believe that this PR does not impact overall performances as it does not add any code that should slow benchmarks.