🚀 Feature Proposal

Native OpenTelemetry instrumentation is being added as part of #2267
From review of part of that work:

It would be good to provide some configurability of the OTel instrumentation.
Similar to how the older diagnostics events can be configured via TransportOptions.diagnostic, there are a couple things that might be nice to be configurable:

1. A way to disable the OTel instrumentation. Users of an OTel SDK will be somewhat used to the ability to disable particular instrumentations. Usually this config var is called enabled, in the context of an instrumentation.
2. A way to suppress child HTTP spans that will be created under the Elasticsearch spans. There are a few existing OTel instrumentations that have this same situation, e.g.: instrumentation-aws-sdk, instrumentation-mongoose. Typically this config var is a boolean called suppressInternalInstrumentation.

AFAIK there aren't any other Node.js libraries that have native OTel instrumentation yet, so there isn't prior art on exactly what to name OTel-related config. Perhaps having this in @elastic/transport:

export interface TransportOptions {
  opentelemetry?: {
    enabled?: boolean;
    suppressInternalInstrumentation?: boolean
  }
  // ...

and the equivalent in interface ClientOptions in @elastic/elasticsearch.

I'm suggesting they get grouped under a "opentelemetry." namespace, because there could be requests for more configuration options as well. For example, see the instrumentation-aws-sdk and instrumentation-mongoose links above.