Use https scheme ins grpc env var exporter examples

[cartermp]

fixes #2861

[hu6360567]

If the endpoint always comes with the scheme, then what's the use of OTEL_EXPORTER_OTLP_INSECURE for?

[svrnm]

If the endpoint always comes with the scheme, then what's the use of OTEL_EXPORTER_OTLP_INSECURE for?

insecure allows self-signed keys

[hu6360567]

If the endpoint always comes with the scheme, then what's the use of OTEL_EXPORTER_OTLP_INSECURE for?

insecure allows self-signed keys

Is it described in any specification?
Seems OTEL_EXPORTER_OTLP_INSECURE in python would affect scheme, rather than validating server certificate.

The OTEL_EXPORTER_OTLP_INSECURE represents whether to enable client transport security for gRPC requests. A scheme of https takes precedence over this configuration setting. Default: False

Also, for signed keys, there should be a way to specify the key server used to verify the server identity, rather than just ignoring the certificate from server.

Will this PR cause a compatibility problem?

I'm fine with the format, as long as the value can be accepted accross the ecosystem.

[svrnm]

If the endpoint always comes with the scheme, then what's the use of OTEL_EXPORTER_OTLP_INSECURE for?

insecure allows self-signed keys

Is it described in any specification? Seems OTEL_EXPORTER_OTLP_INSECURE in python would affect scheme, rather than validating server certificate.

The OTEL_EXPORTER_OTLP_INSECURE represents whether to enable client transport security for gRPC requests. A scheme of https takes precedence over this configuration setting. Default: False

Also, for signed keys, there should be a way to specify the key server used to verify the server identity, rather than just ignoring the certificate from server.

Will this PR cause a compatibility problem?

I'm fine with the format, as long as the value can be accepted accross the ecosystem.

May bad, I was wrong here!

From the spec [1]:

• Insecure: Whether to enable client transport security for the exporter's gRPC connection. This option only applies to OTLP/gRPC when an endpoint is provided without the http or https scheme - OTLP/HTTP always uses the scheme provided for the endpoint. Implementations MAY choose to not implement the insecure option if it is not required or supported by the underlying gRPC client implementation.

I should have done more reading on the issue, I have to admit I was not even aware of that combination of environment variables. From a documentation standpoint having the schema is our best option, it leads to the least issues, since languages MUST support that schema (similar to what @jack-berg stated here about Java: open-telemetry/opentelemetry-java#5517 (comment)).

Outside documentation, if any language does not support schema, this is a bug and needs to be fixed. We can call that out in the documentation until the bug is fixed.

[hu6360567]

It seems the python implementation can accept the export variable with shceme, but when it has conflict with our application when auto-instrument enabled, I'll inspect it later.

[cartermp]

@hu6360567 do you have any issue open here? https://github.com/open-telemetry/opentelemetry-python-contrib

I would bet they're keen on fixing the issue.