Abstract out OTLP http exporter logic

[lorenzoronzani]

Description

This PR contains the refactoring required inside the http_exporter_logic component. The idea is to remove the duplicated code abstracting out inside a common section

Fixes #2990

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)
• Refactor (functionalities are the same, interfaces also but the logic is moved inside codebase)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Executed component specific unit tests using the following command uv run tox -e py312-test-opentelemetry-exporter-otlp-proto-http

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No. No, it's just an internal refactoring

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added/updated
• Documentation has been updated, this is a pure internal refactor, not interfaces update so I don't think that a documentation update it's required

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: lorenzoronzani / name: Lorenzo Ronzani (089a7c7, 09eec1d, 0ae61f2, 0d9175d, 250d7b9, 29c7840, 2aa0053, 3380215, 39723c8, 41d324e, 4405d3e, 44a9b47, 510b7dd, 6cdbc17, 7dec4f5, 88fcdcb, 8c5497e, c80b870, cb3c11c, e21ee19)

[lorenzoronzani]

/easycla

[herin049]

I would recommend reconsidering your approach here. I'm generally not a huge fan of having functions with a huge number of arguments. I'd generally be more in favor of creating a common OTLPHttpClient, as is done in this PR

[lorenzoronzani]

I would recommend reconsidering your approach here. I'm generally not a huge fan of having functions with a huge number of arguments. I'd generally be more in favor of creating a common OTLPHttpClient, as is done in this PR

I was thinking the same but looking around I thought that the implemented method was the one expected. I can convert with a common client class.

Thanks for the review

[lorenzoronzani]

I moved these 3 public constants:

DEFAULT_COMPRESSION
DEFAULT_ENDPOINT
DEFAULT_TIMEOUT

from each exporter (Log, Metric, Trace) into the common one but this uv run tox -e public-symbols-check check now it's failing.

Q: What is the right process in this cases?

[DylanRussell]

can this Enum be part of _SignalConfig and returned directly from OTLPHttpClient

[lorenzoronzani]

Could be but I don't like to much that the parent needs to know children. This because you need to specify a list of types but what about in the future I want to add a new type of exporter? I should edit also the parent class.

What do you think?

[DylanRussell]

This description is sort of obsolete now

[lorenzoronzani]

Thanks for spotting that. I am waiting because I don't know what do we want to do with public constants like what I said in my previous comment. This is important because if we want to proceed with moved them into the parent class this it's a breaking change