OTEL: Update Operation Name to Match Frontend Usage (#1033)

## Overview

OTEL Lambda spans emitted by the
`opentelemetry.instrumentation.aws_lambda` Python instrumentation come
through the Extension with `name: server.request` — the OTEL
semantic-convention generic-server fallback. The Datadog Serverless page
invocation table filters by:

```
operation_name:("aws.lambda" OR "aws.lambda.function"
              OR "opentelemetry_instrumentation_aws_lambda.server"
              OR "opentelemetry.instrumentation.aws_lambda.server")
```

`server.request` matches none of those, so OTEL Lambda functions show 0
traces on the Serverless page even though the spans land in APM
correctly.

This PR overrides the operation name to `aws.lambda` for OTEL Lambda
root-invocation spans on the Extension side. Detection is gated on the
instrumentation scope being `opentelemetry.instrumentation.aws_lambda`
AND span kind being `Server`, so other spans in the trace (HTTP clients,
internal spans, custom spans) are not touched.

## What Changed

`bottlecap/src/otlp/transform.rs` — `get_otel_operation_name_v2`:

- Threads the OTEL `InstrumentationScope` reference through to the
operation-name resolver
- Adds an early branch: `lib.name ==
"opentelemetry.instrumentation.aws_lambda"` AND `span.kind == Server` →
`"aws.lambda"`
- All other spans continue to resolve via the existing HTTP / DB /
messaging / RPC / FAAS / generic fallback chain
- The `lib` parameter was already available at the call site in
`otel_span_to_dd_span`; the change just plumbs it into
`get_otel_operation_name_v2`

## Why on the Extension (vs. logs-backend)

The complementary path — spans arriving through the OTLP endpoint
without going through the Extension — is handled by
DataDog/logs-backend#134974, which performs the
same `server.request → aws.lambda` override in
`SpansOTLPProtobufPayloadParser` along with the broader OTEL → Datadog
field remap (`cloud.resource_id → function_arn`, `faas.invocation_id →
request_id`, etc.).

Doing the override on the Extension side for the Extension-forwarded
path is preferred because:

1. The override is closer to the source of truth — the Extension is the
only component that knows the span came from the OTEL `aws_lambda`
instrumentation
2. APM stats / error tracking / rule-based sampling all see the same
`aws.lambda` name, avoiding "named differently in different places" bugs
3. Mirrors how the Extension already overrides other OTEL-side fields
with Datadog conventions

## Testing

Existing `test_otel_operation_name_*` extended to assert
`server.request` is still produced when the lib name does **not** match
the AWS Lambda scope (regression coverage for the threading change).

New `test_otel_operation_name_aws_lambda` covers three cases:

1. AWS Lambda scope + `Server` kind → `aws.lambda`
2. AWS Lambda scope + `Internal` kind (handler child spans) → unchanged
(`SPAN_KIND_INTERNAL`)
3. Different scope (e.g., `handler`) + `Server` kind → unchanged
(`server.request`)

## Companion PRs

- **logs-backend**
[#134974](DataDog/logs-backend#134974) — same
operation-name override for the OTLP-endpoint path, plus the OTEL →
Datadog field remap
- **web-ui** [#300855](DataDog/web-ui#300855) —
defensive `request_id` fallback in the trace list hook + widened log
queries that match OTLP-ingested logs alongside Datadog Forwarder logs

Together with this PR, OTEL-instrumented AWS Lambda functions (both
endpoint-only and Extension-forwarded) work end-to-end on the Datadog
Serverless page: trace discovery, invocation correlation, function-level
log discovery, error filter, log count.

Author: zarirhamza

bottlecap/src/otlp/transform.rs

@@ -58,6 +58,9 @@ pub const KEY_DATADOG_STATS_COMPUTED: &str = "_dd.stats_computed";
 
 // const SPAN_TYPE_GENERIC_DB: &str = "db";
 
+// AWS Lambda OTEL instrumentation scope name
+const AWS_LAMBDA_INSTRUMENTATION_SCOPE: &str = "opentelemetry.instrumentation.aws_lambda";
+
 // TODO: add mappings
 #[allow(dead_code)]
 static DB_SYSTEM_MAP: LazyLock<HashMap<String, String>> = LazyLock::new(HashMap::new);
@@ -251,7 +254,7 @@ fn get_otel_operation_name_v1(
 }
 
 #[allow(clippy::too_many_lines)]
-fn get_otel_operation_name_v2(otel_span: &OtelSpan) -> String {
+fn get_otel_operation_name_v2(otel_span: &OtelSpan, lib: &OtelInstrumentationScope) -> String {
     let operation_name =
         get_otel_attribute_value_as_string(&otel_span.attributes, "operation.name", false);
     if !operation_name.is_empty() {
@@ -261,6 +264,17 @@ fn get_otel_operation_name_v2(otel_span: &OtelSpan) -> String {
     let is_client = otel_span.kind() == SpanKind::Client;
     let is_server = otel_span.kind() == SpanKind::Server;
 
+    // AWS Lambda: rename the OTEL aws-lambda instrumentation's invocation span (always
+    // emitted with SpanKind::Server) to "aws.lambda" so it matches the Datadog Serverless
+    // page's LAMBDA_INVOCATION_SPAN_FILTER. The span may have a remote parent when the
+    // caller propagates trace context (e.g. API Gateway → Lambda) — that is still the
+    // Lambda invocation span we want to rename. Other spans the same instrumentation
+    // emits (e.g. SDK client spans inside the handler) are not Server kind and pass
+    // through to the existing fallback chain unchanged.
+    if is_server && lib.name == AWS_LAMBDA_INSTRUMENTATION_SCOPE {
+        return "aws.lambda".to_string();
+    }
+
     // HTTP
     let method =
         get_otel_attribute_value_as_string(&otel_span.attributes, "http.request.method", false);
@@ -894,7 +908,7 @@ pub fn otel_span_to_dd_span(
         }
 
         if otel_operation_and_resource_v2_enabled(config.clone()) {
-            dd_span.name = get_otel_operation_name_v2(otel_span);
+            dd_span.name = get_otel_operation_name_v2(otel_span, lib);
         } else {
             dd_span.name = get_otel_operation_name_v1(
                 otel_span,
@@ -1325,6 +1339,55 @@ mod tests {
             get_otel_operation_name_v1(&otel_span, &lib, false, &HashMap::new(), true),
             "opentelemetry_instrumentation_aws_lambda.server"
         );
-        assert_eq!(get_otel_operation_name_v2(&otel_span), "server.request");
+        // With a non-matching lib name, should return server.request
+        assert_eq!(
+            get_otel_operation_name_v2(&otel_span, &lib),
+            "server.request"
+        );
+    }
+
+    #[test]
+    fn test_otel_operation_name_aws_lambda() {
+        // Test that AWS Lambda OTEL instrumentation gets aws.lambda operation name
+        let otel_span = OtelSpan {
+            name: "handler.handler".to_string(),
+            kind: SpanKind::Server as i32,
+            ..Default::default()
+        };
+        let aws_lambda_lib = OtelInstrumentationScope {
+            name: "opentelemetry.instrumentation.aws_lambda".to_string(),
+            version: "0.42b0".to_string(),
+            attributes: [].to_vec(),
+            dropped_attributes_count: 0,
+        };
+
+        // AWS Lambda Server span should return aws.lambda
+        assert_eq!(
+            get_otel_operation_name_v2(&otel_span, &aws_lambda_lib),
+            "aws.lambda"
+        );
+
+        // Non-server span from AWS Lambda instrumentation should NOT return aws.lambda
+        let internal_span = OtelSpan {
+            name: "my-function".to_string(),
+            kind: SpanKind::Internal as i32,
+            ..Default::default()
+        };
+        assert_eq!(
+            get_otel_operation_name_v2(&internal_span, &aws_lambda_lib),
+            "SPAN_KIND_INTERNAL"
+        );
+
+        // Server span from different instrumentation should return server.request
+        let other_lib = OtelInstrumentationScope {
+            name: "handler".to_string(),
+            version: String::new(),
+            attributes: [].to_vec(),
+            dropped_attributes_count: 0,
+        };
+        assert_eq!(
+            get_otel_operation_name_v2(&otel_span, &other_lib),
+            "server.request"
+        );
     }
 }