## Summary of changes

Small perf tweaks for existing `AspNetCoreDiagnosticObserver`

## Reason for change

While experimenting with single span observer, noticed some (safe)
tweaks we could make to the existing implementation. There are some
other improvements we could make as well, but those are a little
riskier, so may be best to delay them.

## Implementation details

- Use `HttpContext.Items[string]` instead of
`HttpContext.Features.Get<T>` as it's a bit faster
- Make `Tracer`/`Security`/`Iast` inputs readonly, instead of using a
null-coalesce with every access
- Move check outside of `AddHeaderTagsToSpan` given common case is to
avoid the function call

## Test coverage

Covered by existing tests

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-842

Part of a stack


- #7962
- #7963 👈
- #7964
- #7966
- #7965

## Summary of changes

Adds a new `DD_TRACE_SINGLE_SPAN_ASPNETCORE_ENABLED` in which we omit
the MVC span

## Reason for change

- Addresses #4093 and partially #1147
- Omitting the MVC span has perf and some usability benefits in some
cases (See issues above). It _does_ mean a certain amount of less
information, particularly in pipeline re-execution scenarios

## Implementation details

- Add a new, disabled by default,
`DD_TRACE_SINGLE_SPAN_ASPNETCORE_ENABLED` for opting in to the new
behaviour.
- .NET 6+ only for various reasons
- Cloned the original observer, deleted everything related to the MVC
span, and then optimized further based on .NET 6+ and other improvements
we can make

## Test coverage

- Added in-process "integration" tests for the observer (more like unit
tests), which mirror the exisitng.
- Added "full" sample-based integration tests for basically all
scenarios we currently test (IIS in process/out of process / MVC /
minimal APIs / proxy spans etc)
- Added snapshots by copying existing, and then updating, so if you look
at the final commit, you can see the diff, which is basically just
"delete the child span"

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-842

Part of a stack



- #7962
- #7963
- #7964 👈
- #7966
- #7965

I experimented with some other perf improvements, but they didn't
provide a significant improvement, so I reverted:
- Caching the resource name by saving it into the `IEndpointMetadata`
collection. The work to do that was too much, and you _can't_ cache in
some cases anyway so not worth it
- Splitting `WebTags` out to remove the IP headers unless we need them.
They're disabled by default, so it just increase the size of the tags
object, but wasn't a big enough improvement to make the complexity worth
it.
- Tried pooling the `RequestTrackingFeature` objects. This one _may_
actually be worth exploring again later, but I didn't see any
improvement in my testing, as they're just not very big and only last 1
request.

---------

Co-authored-by: Lucas Pimentel <lucas.pimentel@datadoghq.com>

## Summary of changes

Creates an optimized version of `AspNetCoreResourceNameHelper` for use
by the single-span Diagnostic observer.

## Reason for change

We have the opportunity for a variety of optimizations thanks to not
creating the MVC span, and the fact that we're .NET 6+. We could
potentially include some or all of these optimizations in the existing
observer path, but for safety/simplicity I'd rather keep it isolated for
now, and we can look at expanding it more broadly later

## Implementation details

- Use the `ValueStringBuilder` to build a resource name
- Don't pre-grab MVC route values, wait to see if we have route params
from them first
- Write directly into the builder as `ToLowerInvariant`, instead of
doing an extra ToLower() at the end

## Test coverage

Added unit tests that use the existing data for the other
implementations, to confirm it's identical. It's also covered indirectly
by the integration tests

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-842

Part of a stack


- #7962
- #7963
- #7964
- #7966 👈
- #7965

…7965)

## Summary of changes

Adds a micro and macro benchmark for the new observer

## Reason for change

Want to verify that it has performance benefits

## Implementation details

- Added new scenario for macro
- Duplicated existing scenario for micro and run. I would like to have
had these as the same methods, but the "global" nature of diagnostic
observers makes this difficult I think.

## Test coverage

I'll manually trigger a run of the macro

## Other details

https://datadoghq.atlassian.net/browse/LANGPLAT-842

Part of a stack



- #7962
- #7963
- #7964
- #7966
- #7965 👈