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

…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 👈