## Summary of changes

Fix profiler integration tests in the SSI run

## Reason for change

#5240 changed the behaviour of the profiler in the presence of SSI
variables. We have a scheduled run on master that specifically sets the
variables. This breaks the profiler integration tests that depend on
those variables.

## Implementation details

Add an "environment restorer" attribute, which mirrors the one we use in
the tracing integration tests. Ensures that the SSI tests are working in
their expected environment

## Test coverage

This is the test, but did [a dedicated run
too](https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=163728&view=results),
and it works

## Other details

Related to #6014

## Summary of changes

Fix the diagnostics associated with the expected state of the continuous
profiler

## Reason for change

In #5240, the continuous profiler gained two new "modes" of operation:
delayed enablement based on heuristics, and "monitoring" mode. The tool
should be updated to understand those possibilities + handle it in the
tests

## Implementation details

- Reset the `DD_INJECTION_ENABLED` variable before running the tests -
the presence/absence of the variable changes the expectations, so we
need to account for it
- Explicitly test the various combinations of `DD_INJECTION_ENABLED` and
`DD_PROFILING_ENABLED`.

## Test coverage

Added additional integration and artifact tests

## Other details

This should address most of the issues in the scheduled SSI run. I
suspect the windows integration tests _may_ need additional work, as
currently the profiler library isn't copied to those tests. Will fix in
this PR if that ends up being the case

Supersedes 
- #5991

---------

Co-authored-by: chrisnas <[email protected]>

## Summary of changes

- Set `_NO_DEBUG_HEAP=1` to fix a timeout issue that only happens on
.NET 6, on Windows, on the scheduled SSI run

## Reason for change

We have a weird issue. Ever since
#5240 was merged, the
scheduled SSI run has been failing on .NET 6 `WindowsIntegrationTests`.
The failure is a timeout, because grabbing a stacktrace becomes _crazy_
expensive - it takes ~10s to call `Environment.StackTrace`.

We (@kevingosse) have looked through multiple dumps, and in all cases
we're in the middle of `ConvertPortablePDB`, which is doing a ultimately
calling `RtlCompareMemoryUlong`.

> This method is basically scanning the memory to make sure that
everything is set to `0xFEEEFEEE` - presumably it's the sentinel value
that the heap uses to detect corruption.

<details><summary>Example stack trace</summary>
<pre><code>[0x0] ntdll!RtlCompareMemoryUlong+0x10 0x40f31971a0
0x7ffea493ed15
[0x1]   ntdll!RtlpAllocateHeap+0x9b5   0x40f31971b0   0x7ffea493c4f9   
[0x2] ntdll!RtlpAllocateHeapInternal+0x6c9 0x40f3197380 0x7ffea4a1c7f6
[0x3] ntdll!RtlDebugAllocateHeap+0xf2 0x40f3197490 0x7ffea49d3762
[0x4] ntdll!RtlpAllocateHeap+0x95402 0x40f31974f0 0x7ffea493c4f9
[0x5] ntdll!RtlpAllocateHeapInternal+0x6c9 0x40f31976c0 0x7ffe5dbd9ad8
[0x6] Microsoft_DiaSymReader_Native_amd64!malloc_base+0x44 0x40f31977d0
0x7ffe5dbc2cef
[0x7] Microsoft_DiaSymReader_Native_amd64!operator new+0x1f 0x40f3197800
0x7ffe5dbc3201
[0x8] Microsoft_DiaSymReader_Native_amd64!operator new+0x9 0x40f3197830
0x7ffe5dcf1754
[0x9]
Microsoft_DiaSymReader_Native_amd64!CDebugSSubSectionEnum::Get+0x154
0x40f3197860 0x7ffe5dcc2b79
[0xa]
Microsoft_DiaSymReader_Native_amd64!Mod1::fUpdateTiOrIdReferencedByNonSyms+0x119
0x40f3197890 0x7ffe5dcc4a2b
[0xb] Microsoft_DiaSymReader_Native_amd64!Mod1::processC13+0x14b
0x40f3197920 0x7ffe5dcc165e
[0xc] Microsoft_DiaSymReader_Native_amd64!Mod1::fProcessSyms+0x126e
0x40f3197bd0 0x7ffe5dcc2a3b
[0xd] Microsoft_DiaSymReader_Native_amd64!Mod1::fUpdateSyms+0x1b
0x40f3197c90 0x7ffe5dcb81cb
[0xe] Microsoft_DiaSymReader_Native_amd64!Mod1::Close+0x1eb 0x40f3197cc0
0x7ffe5dc9d3d3
[0xf]
Microsoft_DiaSymReader_Native_amd64!PortablePDB::ConvertPortablePDB+0x463
0x40f3197d30 0x7ffe5dc86c6e
[0x10] Microsoft_DiaSymReader_Native_amd64!PDB1::OpenPortablePDB+0x9e
0x40f3198670 0x7ffe5dc85c41
[0x11] Microsoft_DiaSymReader_Native_amd64!PDB1::OpenEx2W+0x621
0x40f31986e0 0x7ffe5dc875fe
[0x12] Microsoft_DiaSymReader_Native_amd64!PDB1::OpenValidate4+0x8e
0x40f31987a0 0x7ffe5dcd2a2b
[0x13] Microsoft_DiaSymReader_Native_amd64!LOCATOR::FOpenValidate4+0x8b
0x40f3198850 0x7ffe5dcd1c34
[0x14] Microsoft_DiaSymReader_Native_amd64!LOCATOR::FLocatePdb+0x144
0x40f3198f00 0x7ffe5dc996da
[0x15] Microsoft_DiaSymReader_Native_amd64!PDBCommon::OpenValidate7+0xea
0x40f3199ff0 0x7ffe5dbe847b
[0x16]
Microsoft_DiaSymReader_Native_amd64!CDiaDataSource::loadDataForExeHelper+0xab
0x40f319ae00 0x7ffe5dbe8305
[0x17]
Microsoft_DiaSymReader_Native_amd64!CDiaDataSource::loadDataForExeEx3+0x35
0x40f319af90 0x7ffe5dbb8c78
[0x18] Microsoft_DiaSymReader_Native_amd64!sh::CDiaWrapper::Create+0x158
0x40f319afe0 0x7ffe5dba9bf4
[0x19]
Microsoft_DiaSymReader_Native_amd64!sh::SymReader::InitWithRestrictedSearch+0x94
0x40f319b060 0x7ffe5dbb092e
[0x1a]
Microsoft_DiaSymReader_Native_amd64!sh::SymBinder::GetReaderForFile+0xae
0x40f319b090 0x7ffe8b40852e
[0x1b] coreclr!Module::GetISymUnmanagedReader+0x7ce 0x40f319b0d0
0x7ffe8b4089d2
[0x1c] coreclr!Module::GetISymUnmanagedReaderNoThrow+0x72 0x40f319b320
0x7ffe8b4153e3
[0x1d] coreclr!DebugStackTrace::GetStackFramesInternal+0xa83
0x40f319b3c0 0x7ffe607bb1c2
[0x1e]
System_Private_CoreLib!System.Diagnostics.StackFrameHelper.InitializeSourceInfo+0x42
0x40f319be00 0x7ffe607bb912
[0x1f]
System_Private_CoreLib!System.Diagnostics.StackTrace.CaptureStackTrace+0x42
0x40f319bf00 0x7ffe607bba03
[0x20] System_Private_CoreLib!System.Diagnostics.StackTrace..ctor+0x13
0x40f319bf60 0x7ffe605b431c
[0x21] System_Private_CoreLib!System.Environment.get_StackTrace+0x1c
0x40f319bf90 0x7ffe2bb15da0
[0x22]
Datadog_Trace!Datadog.Trace.Logging.DatadogLogging.GetLoggerFor+0x80
0x40f319bfc0 0x257516f648550000
[0x23]   0x257516f648550000!+   0x40f319bfc8   0x1c8fc9e9000   
[0x24]   0x1c8fc9e9000!+   0x40f319bfd0   0x1c8fd1951c0   
[0x25]   0x1c8fd1951c0!+   0x40f319bfd8   0x1c8fd1951c0   
[0x26]   0x1c8fd1951c0!+   0x40f319bfe0   0x8b267570   
[0x27]   0x8b267570!+   0x40f319bfe8   0x7ffe2b8085a8   
[0x28]   0x7ffe2b8085a8!+   0x40f319bff0   0x40f319c2c8   
[0x29]   0x40f319c2c8!+   0x40f319bff8   0x1c880076070   
[0x2a]   0x1c880076070!+   0x40f319c000   0x0   
</code></pre>
</details> 

What is really weird is the fact that this _only_ happens

- When the SSI variables are enabled (`DD_INJECTION_ENABLED` is set)
- When procdump is attached to capture dumps
- When it's .NET 6, Windows (not .NET 7+, not Linux)

Testing shows that not attaching procdump solves it.

Even more confusing, I _can_ reproduce locally using the following:

```csharp
$env:enable_crash_dumps="true"
.\tracer\build.ps1 BuildTracerHome
.\tracer\build.ps1 BuildAndRunWindowsIntegrationTests --framework net6.0 --filter HttpMessageHandlerTests.HttpClient_SubmitsTraces --sample-name Samples.HttpMessageHandler
```

Note that _locally_ I don't even need to enable the SSI variables 😕 

No, none of this makes any sense to me, I've been digging into this for
days now 🤦‍♂️

The only thing that 100% causes it is procdump. And setting
`_NO_DEBUG_HEAP=1` [disables the debug allocate heap, which solves
it](https://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger/).

I'd _love_ to figure this one out, but given this doesn't _seem_ like it
should be a prod issue, taking the easy option right now, until we can
work out what it is about
#5240 that it doesn't
like 🤷‍♂️

## Test coverage

[I'll trigger a full SSI run to make sure it _is_
solved](https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=165153&view=results)

## Other details

Note that in the Windows integration tests, the profiler isn't
_actually_ available, because we don't download it. But that doesn't
seem to make a difference, because locally when the profiler is there I
still repro