Control instrumentation packages option by environment variable

[jrmdayn]

Is your feature request related to a problem? Please describe

I am using the the OpenTelemetry Operator to auto instrument my NodeJS pods which simplifies a lot the instrumentation setup.
That being said, there are some packages included in the auto-instrumentations-node that I would like more control over. For example, I would like to control some of the optional parameters of the opentelemetry-instrumentation-graphql package (mergeItems, depth etc..).

Describe the solution you'd like to see

The most straightforward solution IMO would be to read the values from the environment with a fallback on the config values passed to the constructor (whichever prevails needs to be determined).
So in the graphql case, I would be able to set:

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  env:
    - name: OTEL_INSTRUMENTATION_GRAPHQL_DEPTH_LIMIT
       value: 2
    - name: OTEL_INSTRUMENTATION_GRAPHQL_MERGE_ITEMS
       value: true

Describe alternatives you've considered

• One alternative would be to not use the Operator to inject auto instrumentation, but instead use a custom registerAutoInstrumentation.js file that I --require when launching my app. In there I can have total control over the options I pass to the various instrumentations.
  -> this is more cumbersome and error prone IMO as I have to explicitly write the registerAutoInstrumentation.js file and use it every where I launch my apps.

• Another alternative would be to modify my Instrumentation CRD so that the NodeJS spec uses a different image, for ex: Image: ghcr.io/my-image:latest
  -> this is better than the previous approach but a bit cumbersome as I have to publish a docker image (forking autoinstrumentation-nodejs:0.53.0) and republish a new image on every update of autoinstrumentation-nodejs

Additional context

[vlepot]

I have the same issue trying to filter some routes I don't want to instrument (like health check routes for instance) and I had to do your second alternative, which is indeed less maintainable