## Summary of changes

Adds a `ValueStringBuilder` implementation, based on the one used
internally in the .NET runtime

## Reason for change

- We can stackalloc the `Span<char>`
- It's a bit faster than our existing `StringBuilderCache`
implementation, and in some places that matters.

## Implementation details

- Made in .NET 6 only for simplicity. We _could_ expose it earlier, but
I wanted this for the updated aspnetcore integration, so .NET6+ only for
now is good enough
- It's not without risks in its usage, so we have to be careful about
things like passing it around (i.e. avoid doing that completely, for
safety)
- Uses an array pool backed implementation (again, built into .NET 6)

## Test coverage

Imported the unit tests from the runtime too

## Other details

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

Part of a stack

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

## 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

## Summary of changes

Fixes the broken build in the benchmarks

## Reason for change

#7965 broke the benchmark
build for some TFMs. I think the race condition between creating a PR
and running the benchmarks meant we didn't notice the failure,
especially because the run still took 30+ mins because it worked in
_some_ TFMs

## Implementation details

- Ensure we have the dummy benchmark for TFMs that don't support it
- Fix some minor spurious warnings

## Test coverage

This is the test, I'll carefully check the run this time