## Summary of changes

This PR addresses the issue
#6045

## Reason for change

When using the `dlsym` function, the compiler adds in the import symbols
table that we need the `dlsym` symbol.
Before being a universal binary (same binary used for glibc-based linux
and musl-libc-based linux) and the compiler added in a `DT_NEEDED`
section the library `libdl.so` (the library containing `dlsym`). When
the wrapper is loaded, it will look through all the `DT_NEEDED` sections
to find a library that contains the `dlsym` symbol.
Since being a universal binary, the `DT_NEEDED` sections are removed
(part of being universal) and we have to resolve by hand needed symbols
(`dlsym`, `pthread_once` ..).
If we use `dlsym` (or other symbol), we will hit this issue.

## Implementation details

- use `__dd_dlsym` instead

## Test coverage

Added a snapshot test using `nm` that verifies that the undefined
symbols in the universal binary haven't changed. It's equivalent to
running

```bash
nm -D Datadog.Linux.ApiWrapper.x64.so | grep ' U ' | awk '{print $2}' | sed 's/@.*//' | sort
```

but done using Nuke instead. It would probably make sense for this to be
a "normal" test in the native tests, but given it has a dependency on
`nm`, which is _definitely_ available in the universal build dockerfile
it was quicker and easier to get this up and running directly. When it
fails, it prints the diff and throws an exception, e.g.

```bash
System.Exception: Found differences in undefined symbols (dlsym) in the Native Wrapper library. Verify that these changes are expected, and will not cause problems. Removing symbols is generally a safe operation, but adding them could cause crashes. If the new symbols are safe to add, update the snapshot file at C:\repos\dd-trace-dotnet\tracer\test\snapshots\native-wrapper-symbols-x64.verified.txt with the new values
```

## Other details

This will be hotfixed onto 3.3.1 and 2.59.1

---------

Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>

This PR addresses the issue
#6045

When using the `dlsym` function, the compiler adds in the import symbols
table that we need the `dlsym` symbol.
Before being a universal binary (same binary used for glibc-based linux
and musl-libc-based linux) and the compiler added in a `DT_NEEDED`
section the library `libdl.so` (the library containing `dlsym`). When
the wrapper is loaded, it will look through all the `DT_NEEDED` sections
to find a library that contains the `dlsym` symbol.
Since being a universal binary, the `DT_NEEDED` sections are removed
(part of being universal) and we have to resolve by hand needed symbols
(`dlsym`, `pthread_once` ..).
If we use `dlsym` (or other symbol), we will hit this issue.

- use `__dd_dlsym` instead

Added a snapshot test using `nm` that verifies that the undefined
symbols in the universal binary haven't changed. It's equivalent to
running

```bash
nm -D Datadog.Linux.ApiWrapper.x64.so | grep ' U ' | awk '{print $2}' | sed 's/@.*//' | sort
```

but done using Nuke instead. It would probably make sense for this to be
a "normal" test in the native tests, but given it has a dependency on
`nm`, which is _definitely_ available in the universal build dockerfile
it was quicker and easier to get this up and running directly. When it
fails, it prints the diff and throws an exception, e.g.

```bash
System.Exception: Found differences in undefined symbols (dlsym) in the Native Wrapper library. Verify that these changes are expected, and will not cause problems. Removing symbols is generally a safe operation, but adding them could cause crashes. If the new symbols are safe to add, update the snapshot file at C:\repos\dd-trace-dotnet\tracer\test\snapshots\native-wrapper-symbols-x64.verified.txt with the new values
```

This will be hotfixed onto 3.3.1 and 2.59.1

---------

Co-authored-by: Andrew Lock <andrew.lock@datadoghq.com>

## Summary of changes

This PR addresses the issue
#6045

## Reason for change

When using the `dlsym` function, the compiler adds in the import symbols
table that we need the `dlsym` symbol.
Before being a universal binary (same binary used for glibc-based linux
and musl-libc-based linux) and the compiler added in a `DT_NEEDED`
section the library `libdl.so` (the library containing `dlsym`). When
the wrapper is loaded, it will look through all the `DT_NEEDED` sections
to find a library that contains the `dlsym` symbol. Since being a
universal binary, the `DT_NEEDED` sections are removed (part of being
universal) and we have to resolve by hand needed symbols (`dlsym`,
`pthread_once` ..).
If we use `dlsym` (or other symbol), we will hit this issue.

## Implementation details

- use `__dd_dlsym` instead

## Test coverage

Added a snapshot test using `nm` that verifies that the undefined
symbols in the universal binary haven't changed. It's equivalent to
running

```bash
nm -D Datadog.Linux.ApiWrapper.x64.so | grep ' U ' | awk '{print $2}' | sed 's/@.*//' | sort
```

but done using Nuke instead. It would probably make sense for this to be
a "normal" test in the native tests, but given it has a dependency on
`nm`, which is _definitely_ available in the universal build dockerfile
it was quicker and easier to get this up and running directly. When it
fails, it prints the diff and throws an exception, e.g.

```bash
System.Exception: Found differences in undefined symbols (dlsym) in the Native Wrapper library. Verify that these changes are expected, and will not cause problems. Removing symbols is generally a safe operation, but adding them could cause crashes. If the new symbols are safe to add, update the snapshot file at C:\repos\dd-trace-dotnet\tracer\test\snapshots\native-wrapper-symbols-x64.verified.txt with the new values
```

## Other details

This is a hotfix for 
- #6048

Co-authored-by: Gregory LEOCADIE <gregory.leocadie@datadoghq.com>

## Summary of changes

This PR addresses the issue
#6045

## Reason for change

When using the `dlsym` function, the compiler adds in the import symbols
table that we need the `dlsym` symbol.
Before being a universal binary (same binary used for glibc-based linux
and musl-libc-based linux) and the compiler added in a `DT_NEEDED`
section the library `libdl.so` (the library containing `dlsym`). When
the wrapper is loaded, it will look through all the `DT_NEEDED` sections
to find a library that contains the `dlsym` symbol. Since being a
universal binary, the `DT_NEEDED` sections are removed (part of being
universal) and we have to resolve by hand needed symbols (`dlsym`,
`pthread_once` ..).
If we use `dlsym` (or other symbol), we will hit this issue.

## Implementation details

- use `__dd_dlsym` instead

## Test coverage

Added a snapshot test using `nm` that verifies that the undefined
symbols in the universal binary haven't changed. It's equivalent to
running

```bash
nm -D Datadog.Linux.ApiWrapper.x64.so | grep ' U ' | awk '{print $2}' | sed 's/@.*//' | sort
```

but done using Nuke instead. It would probably make sense for this to be
a "normal" test in the native tests, but given it has a dependency on
`nm`, which is _definitely_ available in the universal build dockerfile
it was quicker and easier to get this up and running directly. When it
fails, it prints the diff and throws an exception, e.g.

```bash
System.Exception: Found differences in undefined symbols (dlsym) in the Native Wrapper library. Verify that these changes are expected, and will not cause problems. Removing symbols is generally a safe operation, but adding them could cause crashes. If the new symbols are safe to add, update the snapshot file at C:\repos\dd-trace-dotnet\tracer\test\snapshots\native-wrapper-symbols-x64.verified.txt with the new values
```

## Other details

This is a hotfix for 
- #6048

Co-authored-by: Gregory LEOCADIE <gregory.leocadie@datadoghq.com>

… native loader (#7224)

## Summary of changes

Adds more "native symbol" snapshot tests for the symbols we depend on in
our native libraries

## Background

As [part of the initial work on "universal
binaries"](#6048) we had
to [fix an
issue](#6045) where we
accidentally started depending on a new symbol, which was not always
guaranteed to be present and could break customers. As a consequence, we
subsequently set-up snapshot tests that [use
`nm`](https://en.wikipedia.org/wiki/Nm_(Unix)) to dump the symbols
required by our "native wrapper library" AKA
`Datadog.Linux.ApiWrapper.x64.so`. We also added verification checks
that we were building against the correct glibc version so we didn't
accidentally change our supported distros.

## Reason for change

.NET 10 [has bumped](dotnet/runtime#109939)
the minimum supported version of Alpine from 3.13 ([.NET
9<](https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md#linux-compatibility))
to 3.17 ([.NET
10+](https://github.com/dotnet/core/blob/main/release-notes/10.0/supported-os.md#linux-compatibility)).
My _previous_ understanding was that musl is essentially unversioned, so
they're essentially also forward compatible.

Unfortunately, that is apparently not true. Attempting to run .NET 10 on
Alpine 3.13 does not work, and it specifically fails with a `symbol not
found` error:

```
Failed to load /usr/share/dotnet/host/fxr/10.0.0-preview.5.25277.114/libhostfxr.so, error: 
Error relocating /usr/share/dotnet/host/fxr/10.0.0-preview.5.25277.114/libhostfxr.so: 
_ZSt28__throw_bad_array_new_lengthv: symbol not found
```

So this leaves us with a dilemma; we need to update to alpine 3.17 so we
can build and test with .NET 10, but doing so _might_ end up introducing
breaking dependencies on new symbols.

This PR is about _documenting_ more fully what we actually depend on.
Currently we have

- Symbol tests for `Datadog.Linux.ApiWrapper.x64.so` on `linux-x64` and
`linux-arm64`
- Maximum GLibc usages verification for `linux-x64` and `linux-arm64`
for
  - `Datadog.Tracer.Native.so`
  - `Datadog.Profiler.Native.so`
  - `libdatadog_profiling.so`

This PR adds additional tests for the missing libraries and targets

- Symbol tests for `Datadog.Trace.ClrProfiler.Native.so` on `linux-x64`
and `linux-arm64`
- Symbol tests  for `linux-musl-x64` and `linux-musl-arm64` for
  - `Datadog.Tracer.Native.so`
  - `Datadog.Profiler.Native.so`
  - `libdatadog_profiling.so`

> Note that `Datadog.Linux.ApiWrapper.x64.so` and
`Datadog.Trace.ClrProfiler.Native.so` are "universal" binaries, so the
same binary is used for both Glibc and musl.

## Implementation details

- Extracted the existing symbol test to a reusable function (1st commit,
feel free to skip).
- Call the reusable function in the missing scenarios.
- Run the tests and save the snapshots.

## Test coverage

More now! 

Note that I'm not really sure how much value there is in documenting the
`libdatadog_profiling.so` symbols. It's not something we control in this
repository and it means needing to update the snapshot when something
changes. I've included it now to be safe, but we can always address
later.

## Other details

Investigating the alpine:3.17 changes is out of scope for this PR, I'll
investigate that separately.

The one notably not-documented native library here is ddwaf. Should we
document the symbols in that one too?