Adding support for setting OTLP exporter protocol by env vars

[ronyis]

Description

Fixes #2586

Adding support for specifying OTLP export protocol using env vars, as defined in the specifications.

Since the SDK already supports setting the protocol using the values otlp_proto_grpc and otlp_proto_http of OTEL_TRACES_EXPORTER, these values are still supported and have priority over the new supported variables. In case of conflict, a warning will be printed.

Future support for configuring metrics and logs with HTTP exporter is already added, although those do not exist yet, therefore will result in a RuntimeError.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• opentelemetry-sdk/tests/test_configurator.py::TestExporterNames

Does This PR Require a Contrib Repo Change?

See open-telemetry/opentelemetry-python-contrib#1250
Contrib repo change is not necessarily required, but it is related to fixing the same issue.

Checklist:

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: ronyis / name: Ron Yishai (0ef86ee)

[galbash]

in the PR you mentioned:

Since the SDK already supports setting the protocol using the values otlp_proto_grpc and otlp_proto_http of OTEL_TRACES_EXPORTER, these values are still supported and have priority over the new supported variables. In case of conflict, a warning will be printed.

Is our goal to deprecate otlp_proto_grpc/http over time or discourage the use of them? if so maybe we should issue a deprecation warning / log

[ronyis]

in the PR you mentioned:

Since the SDK already supports setting the protocol using the values otlp_proto_grpc and otlp_proto_http of OTEL_TRACES_EXPORTER, these values are still supported and have priority over the new supported variables. In case of conflict, a warning will be printed.

Is our goal to deprecate otlp_proto_grpc/http over time or discourage the use of them? if so maybe we should issue a deprecation warning / log

@srikanthccv what do you think about that?

[srikanthccv]

Ideally we should deprecate them. It may be our shortsightedness because the way this going - for someone who is Installing just the *-proto-http package why do they need need to configure *_PROTOCOL again to get it to work correctly.

[ronyis]

I think it's OK that the user will have to explicitly specify the OTLP protocol in case he doesn't use the default value.
We can also add the functionality of trying to import the HTTP exporter, in case the gRPC one isn't found. Personally, I think that it should better be defined in the specifications first.