Allow end-user customisation of services extensions in @opentelemetry/instrumentation-aws-sdk

[chrisrichardsevergreen]

The customisation of how @opentelemetry/instrumentation-aws-sdk handles specific AWS services is limited to those pre-built into the package (SNS, SQS, dynamodb). This limits end-user customisability, resulting in either a need to fork or write custom clientside code. For example if a user wants to propagate tracecontext into a SDK lambda invocation they would have to manage this themselves, and AFAICT would not be able to access the inner aws-sdk span ID anyway. The may also wish to customise how SQS/SNS/DynamoDB context is propagated, which is not supported either.

Describe the solution you'd like to see

If AwsSdkInstrumentationConfig allowed the user to provide custom service extensions these could be added into ServicesExtensions to handle services other than SQS, SNS and dynamodb, or to handle SQS, SNS and dynamodb in different ways if the user desired.

e.g.

export interface AwsSdkServiceExtensionDefinition {
   serviceName: string;
   extension: ServiceExtension;
}
export interface AwsSdkInstrumentationConfig extends InstrumentationConfig {
  preRequestHook?: AwsSdkRequestCustomAttributeFunction;
  responseHook?: AwsSdkResponseCustomAttributeFunction;
  sqsProcessHook?: AwsSdkSqsProcessCustomAttributeFunction;

  customServiceExtensions?: AwsSdkServiceExtensionDefinition[];
  suppressInternalInstrumentation?: boolean;
  sqsExtractContextPropagationFromPayload?: boolean;
}

These could then be added via the ServicesExtensions constructor (to avoid changing the interface).

Describe alternatives you've considered

Fairly new to opentelemetry so if I've missed anything obvious about passing context into lambda invokes using the SDK I apologise, however the approach we've taken so far (adding to the payload in user code) leaves the aws-sdk instrumented span 'orphaned' (the lambda's span from tracecontext ends up having the active span as the active span when the payload is built.

However more than happy to implement and submit a PR if this would be welcomed.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[chrisrichardsevergreen]

The underlying motivation for this issue has been achieved in PR #916 so this can be closed.