## Summary of changes

When implementing baggage in #6157., we changed the logic in
`HttpMessageHandlerCommon` so that it would propagate baggage even if
the http client integration was disabled. This changes this behavior so
that headers are only injected if the integration is enabled.

Bonus change: cleaned up the integration tests that were modified in
this PR
- added `StringUtil.GetAllHeaders()` so we only run the `Regex` once on
the stdout instead of a separate regex for each header
- use `FluentAssertions`
- use modern C# constructs like `var` and `using` statements (I
recommend ignoring whitespace when viewing the diff)

## Reason for change

This behavior is more correct. Disabling the integration should mean the
integration doesn't change any app behavior at all, including injecting
http headers. There are separate settings to disable trace and baggage
propagators, if needed.

## Implementation details

Move the `Inject()` call into the `if(enabled)` block, where it used to
be before #6157.

## Test coverage

- Added assertions to
`HttpMessageHandlerTests.TracingDisabled_DoesNotSubmitsTraces()` to
verify that _none_ of the known propagation headers are injected when
integration is disabled (not just `baggage`).

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

## Summary of changes

When implementing baggage in #6157., we changed the logic in
`HttpMessageHandlerCommon` so that it would propagate baggage even if
the http client integration was disabled. This changes this behavior so
that headers are only injected if the integration is enabled.

Bonus change: cleaned up the integration tests that were modified in
this PR
- added `StringUtil.GetAllHeaders()` so we only run the `Regex` once on
the stdout instead of a separate regex for each header
- use `FluentAssertions`
- use modern C# constructs like `var` and `using` statements (I
recommend ignoring whitespace when viewing the diff)

## Reason for change

This behavior is more correct. Disabling the integration should mean the
integration doesn't change any app behavior at all, including injecting
http headers. There are separate settings to disable trace and baggage
propagators, if needed.

## Implementation details

Move the `Inject()` call into the `if(enabled)` block, where it used to
be before #6157.

## Test coverage

- Added assertions to
`HttpMessageHandlerTests.TracingDisabled_DoesNotSubmitsTraces()` to
verify that _none_ of the known propagation headers are injected when
integration is disabled (not just `baggage`).

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

## Summary of changes

When implementing baggage in #6157., we changed the logic in
`HttpMessageHandlerCommon` so that it would propagate baggage even if
the http client integration was disabled. This changes this behavior so
that headers are only injected if the integration is enabled.

Bonus change: cleaned up the integration tests that were modified in
this PR
- added `StringUtil.GetAllHeaders()` so we only run the `Regex` once on
the stdout instead of a separate regex for each header
- use `FluentAssertions`
- use modern C# constructs like `var` and `using` statements (I
recommend ignoring whitespace when viewing the diff)

## Reason for change

This behavior is more correct. Disabling the integration should mean the
integration doesn't change any app behavior at all, including injecting
http headers. There are separate settings to disable trace and baggage
propagators, if needed.

## Implementation details

Move the `Inject()` call into the `if(enabled)` block, where it used to
be before #6157.

## Test coverage

- Added assertions to
`HttpMessageHandlerTests.TracingDisabled_DoesNotSubmitsTraces()` to
verify that _none_ of the known propagation headers are injected when
integration is disabled (not just `baggage`).

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

## Summary of changes

When the EventBridge instrumentation is disabled we should not inject
headers / context into the object. This was the case initially in
#6096, but appears to
have been accidentally removed in a refactoring in
#6157.

## Reason for change

Appears that we do not entirely support certain message types here.

## Implementation details

Essentially restored the `if (scope?.Span.Context is { } context)` check
before injecting.

## Test coverage

Our test coverage _passes_ with / without this as we correctly don't
create a span when the instrumentation is disabled but we don't really
have the means to assert that we do not modify the underlying objects in
some way. This is potentially something we should look into
implementation to catch future issues like this potentially.

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