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

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 👈