opentelemetry-exporter-otlp-proto-http: Generalize OTLP HTTP exporters to allow using alternative HTTP clients

[herin049]

Description

Refinement of #5164

Motivation

The three OTLP/HTTP signal exporters previously each carried a duplicated copy of session setup, compression, and retry/backoff logic. This PR introduces a BaseHTTPTransport ABC so the underlying HTTP library is swappable, and switches the exporters to urllib3 by default (a lighter weight alternative to requests)

Note that as implemented in this PR, backwards compatibility is preserved. In the case that the legacy session parameter is passed in, or a credential provider is provided via the OTEL_PYTHON_EXPORTER_OTLP_HTTP_*_CREDENTIAL_PROVIDER environment variable, the RequestsHTTPTransport will be used instead of the Urllib3HTTPTransport.

One open question for maintainers is if we think it safe to drop requests as a required dependency. Given that the RequestsHTTPTransport will only be used if the user explicitly passes a requests session into the constructor or initializes OTEL_PYTHON_EXPORTER_OTLP_HTTP_*_CREDENTIAL_PROVIDER environment variable, it is mostly safe to assume that the user must already have requests installed as a dependency. If the user does not manually construct a session, requests will no longer be imported/used - hence it's preferable to remove it as a dependency. The only "breaking" change is that requests will no longer be a transitive dependency of the exporter package, so any users relying on this will encounter an import error.

Follow-ups:

• Additional transport implementations can be added behind the same ABC (e.g. httpx, urllib, etc.).
• An opentelemetry_otlp_http_transport entry point + OTEL_PYTHON_OTLP_HTTP_TRANSPORT env var can be added up so users can plug in a custom transport implementation without code changes.

Fixes #3439 and #4171

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Tox

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[DylanRussell]

If we were ok with dropping requests entirely, we could also get rid of the custom retry/backoffs code and use https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#utilities

[herin049]

If we were ok with dropping requests entirely, we could also get rid of the custom retry/backoffs code and use https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#utilities

Great suggestion, although my thought is that we should still stick to explicitly handling retries in the OTLPHTTPClient because it makes transport implementations easier to implement, and it doesn't put the burden of retries on the transport implementation itself. I think we still want to ensure these changes are fully backwards compatible, so we'd still accept a requests.Session, and in the future add support for httpx.