traceGRPCOptions silently ignored the TLSConfig struct that is parsed
from the YAML configuration, while traceHTTPOptions already applied it
correctly via exthttp.NewTLSConfig. As a result, the ca_file, cert_file
and key_file fields had no effect for gRPC clients, even though the
configuration was valid and the values were present.

Without TLS credentials being supplied to the gRPC dialer, the exporter
fell through to the default credentials.NewTLS(nil) path in the OTel SDK
which only trusts system root CAs. Any deployment using a private or
internal CA therefore failed with:

  transport: authentication handshake failed: tls: failed to verify
  certificate: x509: certificate signed by unknown authority

The only available workaround was to supply the OTEL_EXPORTER_OTLP_CERTIFICATE,
OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE and OTEL_EXPORTER_OTLP_CLIENT_KEY
environment variables directly, bypassing the Thanos configuration entirely.

Fix this by mirroring the HTTP behaviour: when insecure is false, build a
*tls.Config from the parsed TLSConfig via exthttp.NewTLSConfig and pass it
to the gRPC exporter as credentials.TransportCredentials via
WithTLSCredentials. This enables ca_file (custom CA verification), cert_file
and key_file (mTLS client authentication) to work correctly for gRPC.

Signed-off-by: roth-wine <[email protected]>

Before the fix in the preceding commit, the tls_config fields ca_file,
cert_file and key_file were silently ignored by traceGRPCOptions, making
it impossible to verify through existing tests that TLS configuration
was actually applied to the gRPC exporter. This commit adds a test that
directly validates the fix by exercising the full export path against a
real TLS-secured gRPC server.

The test spins up an in-process gRPC server secured with a self-signed
ECDSA certificate issued by a private CA (not present in the system
trust store). It then configures NewTracerProvider with client_type: grpc
and tls_config.ca_file pointing to that CA certificate. A span is created
and tp.Shutdown is called to force a synchronous flush, which triggers the
actual gRPC connection and TLS handshake. If tls_config.ca_file were not
applied to the gRPC dialer, the TLS handshake would fail with:

  x509: certificate signed by unknown authority

and tp.Shutdown would return an error, failing the test.

The test infrastructure consists of:
- generateTestCert: generates a self-signed ECDSA P-256 certificate in
  memory, valid for 127.0.0.1, usable as both CA and server certificate.
- startTLSGRPCServer: starts a grpc.Server with TLS credentials and
  registers a minimal mock OTLP TraceService that accepts any export
  request, ensuring the full export RPC succeeds once TLS is established.

Signed-off-by: roth-wine <[email protected]>