feat(datadog-aws): add per-service interceptor crates for SQS, SNS, and EventBridge

[Dogbu-cyber]

PR Stack: #194 (workspace setup) -> #189 (aws-sdk injection)

What does this PR do?

Adds trace context injection for the AWS SDK for Rust via three focused interceptor crates. Each crate pulls in only the AWS SDK dependency it needs -- users add only what they use.

Ref: #190

Crate architecture

instrumentation/
├── datadog-aws-core/       # shared -- ServiceHandler trait, generic AwsInterceptor,
│                           #            attribute_keys, limits
├── datadog-aws-core-test-utils/       # common test helpers (not published)
├── datadog-aws-sqs/        # SqsInterceptor
├── datadog-aws-sns/        # SnsInterceptor
└── datadog-aws-eventbridge/ # EventBridgeInterceptor

Usage

use datadog_aws_sns::ConfigExt as _;

let sns = aws_sdk_sns::Client::from_conf(config.to_builder()
  .datadog_tracing() // instrument
  .build());

Supported operations

Service	Inject operations	Tag-only operations	Injection point
SQS	SendMessage, SendMessageBatch	ReceiveMessage, DeleteMessage, DeleteMessageBatch	_datadog MessageAttribute (String, JSON)
SNS	Publish, PublishBatch	GetTopicAttributes, ListSubscriptionsByTopic, Subscribe, CreateTopic, etc.	_datadog MessageAttribute (Binary) -- avoids subscription filter policy interference
EventBridge	PutEvents	PutRule, PutTargets, DescribeRule, etc.	_datadog key in event detail JSON

Each interceptor also creates a client span (sqs.request, sns.request, eventbridge.request) with standard Datadog tags: aws.service, aws.operation, aws.region, aws.partition, resource.name, operation.name, etc.

Design notes

• datadog-aws-core exposes shared request span helpers and common attributes; each service crate owns its concrete AWS SDK interceptor implementation and uses those helpers for span lifecycle, service-specific tags, and trace-context injection.
• Injection never fails an AWS call -- errors are swallowed and logged at debug level
• SQS/SNS respect the 10-attribute cap but overwrite a stale _datadog attribute if present
• EventBridge skips injection if the resulting detail would exceed 1 MB
• Integration test infrastructure (mock_aws, init_test_tracer, sdk_config, span_attrs) lives in datadog-aws-core-test-utils

Trace Example

[ygree]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 302fbb5267

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[joeyzhao2018]

LGTM

[Dogbu-cyber]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80424aa3a6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Validate full PutEvents entry size before mutating Detail

The size guard only checks new_detail.len(), but EventBridge enforces the 1 MB limit on the entire PutEventsRequestEntry payload, not just the Detail field. If an entry is already near the limit because of Source, DetailType, Resources, etc., adding _datadog can push the total entry size over quota and make PutEvents fail, even though tracing is intended to be non-intrusive. This should use the documented entry-size calculation (or equivalent full-entry check) before writing the mutated detail.

Useful? React with 👍 / 👎.

[ygree]

TL;DR This is a valid concern. I'm thinking about dropping this check because it's not correct or useful.

The limit is documented as a service-side contract. AWS’s current EventBridge API reference says PutEvents total entry size must be less than 1 MB, and the user guide says the whole request must stay under 1,048,576 bytes, with a single entry allowed to use that full budget if it is the only one. Invalid entries are reported back by the service through PutEventsResultEntry.ErrorCode / ErrorMessage, which is consistent with backend enforcement rather than SDK preflight. Sources: PutEvents API, PutEvents user guide, PutEventsResultEntry.

The latest generated Rust SDK docs still say 256KB

[ygree]

I think we should keep the check for now, just to provide an upper limit. If the payload exceeds the limit for any reason, we can skip the injection path altogether, as such a request will be rejected by the backend anyway.

[purple4reina]

Would be nice to include a debug level log here, or somehow otherwise inform the user why injection failed.

[purple4reina]

In all the cases where we return early, would be nice to have some debug level logging.