feat(instrumentation)!: simplify registerInstrumentations() API

[pichlermarc]

The @opentelemetry/instrumentation package exports a InstrumentationOption type:

export type InstrumentationOption =
  | typeof InstrumentationBase
  | (typeof InstrumentationBase)[]
  | Instrumentation
  | Instrumentation[];

However, InstrumentationBase implements Instrumentation already. Further, this requires extra code to make whats passed to instrumentations just slightly more convenient, for instance it supports:

• A single instrumentation: registerInstrumentations({instrumentations: fooInstrumentation})
• A few instrumentations, nested in sub-arrays: registerInstrumentations({instrumentations: [fooInstrumentation, [barInstrumentation]]})

This PR proposes removing this InstrumentationOption type, and replacing all usages of InstrumentationOption and InstrumentationOption[] with (Instrumentation | Insturmentation[])[]. This drops support for the first case listed above in favor of always having to provide a list of instrumentations. This simplifies the code in both sdk-node and instrumentation.

[trentm]

These aren't arguments against. I'm just pointing them out for discussion.

---

One convenience of having allowed nested arrays was something like:

const sdk = new NodeSDK({
    instrumentations: [
        getNodeInstrumentations(/* ... */), // this ends up being a nested array
        someThirdPartyInstrumentation,
        someOtherThirdPartyInstrumentation,
    ]
});

The fairly simple workaround is to call .flat() oneself:

sdk = new NodeSDK({
    instrumentations: [
        getNodeInstrumentations(/* ... */), // this ends up being a nested array
        someThirdPartyInstrumentation,
        someOtherThirdPartyInstrumentation,
    ].flat()
});

So I suppose that is fine.

2. IIUC this also drops support for passing in an uninstantiated Instrumentation class:

sdk = new NodeSDK({
    instrumentations: [
        HttpInstrumentation,  // class <--- this thing would no longer be supported
        new ExpressInstrumentation(),  // instance
    ]
});

To be honest, I was surprised that passing in just the class was supported at all when I first noticed it a while back.

[pichlermarc]

@trentm I see, I did not consider that. Actually keeping support for this is pretty straightforward so I'd keep it around, but only drop the InstrumentationBase one, so I've replaced InstrumentationOptions with (Instrumentation | Instrumentation[])[] which is reasonably simple to deal with when used. 065566d

Since opening the PR I've also seen that we recommend this way in our docs so it's probably better to keep it around.

To be honest, I was surprised that passing in just the class was supported at all when I first noticed it a while back.

Yes I'm also surprised that this works. I updated the changelog to reflect that this is not an option anymore. 970e57b