## Summary of changes

Ensure the profiler files are available in the execution benchmarks

## Reason for change

While working on #7287, we discovered that the profiler was not
downloaded, which was causing a stable config PInvoke to fail. To more
closely replicate customer environments, we should ensure the profiler
is available in these benchmarks, as it will impact startup time etc.

> Note that we are introducing a separate mitigation in #7287 to handle
the scenario where the profiler is not available, e.g. in serverless
environments

## Implementation details

Download the `windows-profiler-home` artifact. Note that the
`windows-tracer-home` artifact is _already_ available thanks to the
`restore-working-directory` step, so it's not necessary to re-download
it.

## Test coverage

This is the test, we'll examine the benchmarks out of interest to see if
there's any impact, but fundamentally this is the more "correct"
behaviour anyway.

## Other details

Blocks #7287

## Summary of changes

Add a checker to decide whether the profiler is available

## Reason for change

We are going to be (and are currently) making P/Invoke calls on startup
to call the profiler. If the ClrProfiler is not attached, or the CP file
is not available (and so P/Invokes are not re-written) then this can
cause additional delays.

## Implementation details

Add explicit checks for
- Unsupported environments
- Has the profiler set the "profiler available" env var (only works on
Windows right now)
- Are we in known unsupported environments (lambda and Azure functions
outside of AAS extension)
- Is the ClrProfiler attached

## Test coverage

If everything still works, this _should_ work

## Other details

A blocker for #7287

## Summary of changes

Skip failing TraceAnnotationsTests in .NET 6.0

## Reason for change

Started failing after
#7287

## Implementation details

Just a dumb Skip.If to skip for the time if we are in .NET 6.0

## Test coverage

## Other details
<!-- Fixes #{issue} -->


<!--  ⚠️ Note:

Where possible, please obtain 2 approvals prior to merging. Unless
CODEOWNERS specifies otherwise, for external teams it is typically best
to have one review from a team member, and one review from apm-dotnet.
Trivial changes do not require 2 reviews.

MergeQueue is NOT enabled in this repository. If you have write access
to the repo, the PR has 1-2 approvals (see above), and all of the
required checks have passed, you can use the Squash and Merge button to
merge the PR. If you don't have write access, or you need help, reach
out in the #apm-dotnet channel in Slack.
-->

## Summary of changes

Skip failing TraceAnnotationsTests in .NET 6.0

## Reason for change

Started failing after
#7287

## Implementation details

Just a dumb Skip.If to skip for the time if we are in .NET 6.0

## Test coverage

~~I missed this one in
#7551 😢~~

I did the wrong one in
#7551 after looking at
the logs again

## Other details
<!-- Fixes #{issue} -->


<!--  ⚠️ Note:

Where possible, please obtain 2 approvals prior to merging. Unless
CODEOWNERS specifies otherwise, for external teams it is typically best
to have one review from a team member, and one review from apm-dotnet.
Trivial changes do not require 2 reviews.

MergeQueue is NOT enabled in this repository. If you have write access
to the repo, the PR has 1-2 approvals (see above), and all of the
required checks have passed, you can use the Squash and Merge button to
merge the PR. If you don't have write access, or you need help, reach
out in the #apm-dotnet channel in Slack.
-->

## Summary of changes

Fixes flakiness in the `TraceAnnotation` tests

## Reason for change

#7287 incidentally
introduced flakiness in the test when the profiler is not available
(i.e. only on Windows). We temporarily disabled the test in #7551 and
#7552. This reinstates the test, and removes the flake.

## Implementation details

The important thing is that we do a "real" instrumentation in the app,
to insure that we send instrumentation telemetry. Without this, there's
a race condition between us instrumenting our "own" `HttpClient` usages
and the app ending.

In more detail, we see this flake because:

- The integration telemetry is only sent when something is instrumented
(or subsequently errors)
- The delay in profiling introduced in #7287 causes a delay in sending
the calltarget definitions
  - We will address that delay in a separate PR
- The telemetry thread runs in the background, and is already started
before we P/Invoke into the profiler
- The delay causes us to not instrument the HttpClient calls that the
background telemetry thread makes initially - if we skip the P/Invoke,
then they are instrumented at this point
- The app shuts down, which causes another telemetry flush
- At this point the `HttpClient` calls are instrumented, and the
instrumentation details are collected, but now we're shutting down, so
this data is never sent.

By forcing an instrumentation in the app, we bypass the race condition
entirely.

## Test coverage

Excluded the span from the tests so it's effectively the same. We don't
care about the contents of that span (or whether the request passes or
fails) - we just want to make sure we have instrumentation.

## Other details

… env var (#7555)

## Summary of changes

Update profiler availability helper algorithm on Windows

## Reason for change

- If the Continuous Profiler isn't available, the native loader does not
rewrite P/Invokes and does not set
`DD_INTERNAL_PROFILING_NATIVE_ENGINE_PATH`
- If it is available, the native loader sets the
`DD_INTERNAL_PROFILING_NATIVE_ENGINE_PATH` value
- Currently, the `ProfilerAvailabilityHelper` is treating the presence
of the variable as indication the profiler is available, but it's not
treating the _absence_ as an indication the profiler is _not_ available.
- This PR changes that to treat the
`DD_INTERNAL_PROFILING_NATIVE_ENGINE_PATH` variable as the deciding
factor on Windows

(Note that his variable is _not_ available today on non-Windows as it
doesn't propagate from the native side. We hope to fix that in the
future, but in the mean time we must rely on heuristics).

## Implementation details

Update the logic of the helper on Windows to only rely on the
`DD_INTERNAL_PROFILING_NATIVE_ENGINE_PATH` variable.

Note that I also removed the AAS Extension check, as that only runs on
Windows anyway, so would never return `true` (as it's caught in the
`IsWindows()` branch).

## Test coverage

Updated the unit tests with new behaviour. Basically we need to skip
more tests on Windows, as it's only governed by that flag

## Other details

Related to the following:
- #7554
- #7287
- #7552

## Summary of changes

Updates the rules around `ProfilerSettings` enablement

## Reason for change

After #7287, we decide whether the profiler is enabled in managed code,
instead of on the native side. However, we got some of the rules wrong.
Specifically, we believed that the profiler should behave different when
`DD_INJECTION_ENABLED` was set, but that's not the case. The profiler
should behave the same in all cases.

## Implementation details

Fixed the implementation to ignore the SSI variable, and updated the
corresponding unit tests

## Test coverage

Updated the tests that were affected

## Other details

The incorrect behaviour was actually introduced in #7303, but it didn't
have a visible impact until #7287