…Setup (#398)

## What does this pull request do?
Fixes an issue where
[upgrading](#388)
our OTel dependency version from 1.27.0 caused all of our contract tests
to start
[failing](https://github.com/aws-observability/aws-otel-python-instrumentation/actions/runs/15640951584/job/44067918087)
in the main build.

The root cause was that in version
[1.28.0](https://github.com/open-telemetry/opentelemetry-python-contrib/releases/tag/v0.49b0)
OpenTelemetry Python SDK migrated from `pkg_resources` to
`importlib_metadata` for entry point discovery. This was a [breaking
change](open-telemetry/opentelemetry-python-contrib#2871)
that had significant behavioral implications:
- **Before (pkg_resources):** Entry points were discovered in `sys.path`
order, meaing packages installed in the local test environment (e.g.
venv) were always prioritized. This made ADOT discovery predictable and
consistent even without explicitly specifying `OTEL_PYTHON_DISTRO` and
`OTEL_PYTHON_CONFIGURATOR` in the contract test set up.
- **After (importlib_metadata):** Entry points are discovered using an
implementation ordering that doesn't guarantee `sys.path` precedence. In
short, the discovery order depends on factors like filesystem iteration
order, installation timestamps, etc. - things that can vary between
environments. This is why our contract tests were able to pass in
original PR build to bump the OTel dependencies, but then started
failing in our main build.

Due to this unpredicatable ordering, our ADOT SDK was not able to
instrument the sample apps in our contract tests correctly which then
resulted in all the test assertions failing.

The solution is to explicitly configure the OpenTelemetry distro and
configurator in our contract test set up. This approach follows
OpenTelemetry's [official
recommendations](https://pypi.org/project/opentelemetry-instrumentation/)
when multiple distros are present.
> If you have entry points for multiple distros or configurators present
in your environment, you should specify the entry point name of the
distro and configurator you want to be used via the OTEL_PYTHON_DISTRO
and OTEL_PYTHON_CONFIGURATOR environment variables.

**This fix will enable us to safely upgrade our OTel dependency version
from 1.27.0 which unblocks the Caton project.**


By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice.

…Setup (aws-observability#398)

## What does this pull request do?
Fixes an issue where
[upgrading](aws-observability#388)
our OTel dependency version from 1.27.0 caused all of our contract tests
to start
[failing](https://github.com/aws-observability/aws-otel-python-instrumentation/actions/runs/15640951584/job/44067918087)
in the main build.

The root cause was that in version
[1.28.0](https://github.com/open-telemetry/opentelemetry-python-contrib/releases/tag/v0.49b0)
OpenTelemetry Python SDK migrated from `pkg_resources` to
`importlib_metadata` for entry point discovery. This was a [breaking
change](open-telemetry/opentelemetry-python-contrib#2871)
that had significant behavioral implications:
- **Before (pkg_resources):** Entry points were discovered in `sys.path`
order, meaing packages installed in the local test environment (e.g.
venv) were always prioritized. This made ADOT discovery predictable and
consistent even without explicitly specifying `OTEL_PYTHON_DISTRO` and
`OTEL_PYTHON_CONFIGURATOR` in the contract test set up.
- **After (importlib_metadata):** Entry points are discovered using an
implementation ordering that doesn't guarantee `sys.path` precedence. In
short, the discovery order depends on factors like filesystem iteration
order, installation timestamps, etc. - things that can vary between
environments. This is why our contract tests were able to pass in
original PR build to bump the OTel dependencies, but then started
failing in our main build.

Due to this unpredicatable ordering, our ADOT SDK was not able to
instrument the sample apps in our contract tests correctly which then
resulted in all the test assertions failing.

The solution is to explicitly configure the OpenTelemetry distro and
configurator in our contract test set up. This approach follows
OpenTelemetry's [official
recommendations](https://pypi.org/project/opentelemetry-instrumentation/)
when multiple distros are present.
> If you have entry points for multiple distros or configurators present
in your environment, you should specify the entry point name of the
distro and configurator you want to be used via the OTEL_PYTHON_DISTRO
and OTEL_PYTHON_CONFIGURATOR environment variables.

**This fix will enable us to safely upgrade our OTel dependency version
from 1.27.0 which unblocks the Caton project.**


By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice.