Fix span parenting for isolated Azure Functions with ASP.NET Core integration

When HTTP proxying is enabled (ASP.NET Core integration), the host
makes an HTTP call to the worker process. The HTTP client instrumentation
automatically propagates trace context in HTTP headers.

Previously, we were also injecting the Azure Functions host span context
into the gRPC message, causing worker spans to be incorrectly parented
to the root host span instead of the HTTP client span.

Fix: Skip gRPC context injection when HTTP proxying is enabled, allowing
the HTTP client instrumentation to handle context propagation naturally.

This ensures worker spans are properly parented to the HTTP call span,
creating the correct span hierarchy:
- Root: azure_functions.invoke (host)
  - http.request: GET localhost:port (host -> worker)
    - azure_functions.invoke (worker)
      - (worker child spans)

Fixes APMSVLS-58

Author: lucaspimentel

tracer/src/Datadog.Trace/ClrProfiler/AutoInstrumentation/Azure/Functions/Isolated/GrpcMessageConversionExtensionsToRpcHttpIntegration.cs

@@ -49,8 +49,7 @@ internal static TReturn OnAsyncMethodEnd<TTarget, TReturn>(TTarget nullInstance,
         }
 
         var tracer = Tracer.Instance;
-        if (!tracer.Settings.IsIntegrationEnabled(AzureFunctionsCommon.IntegrationId)
-         || tracer.ActiveScope is not Scope { Span: { OperationName: AzureFunctionsCommon.OperationName } span })
+        if (!tracer.Settings.IsIntegrationEnabled(AzureFunctionsCommon.IntegrationId))
         {
             return returnValue;
         }
@@ -76,19 +75,32 @@ internal static TReturn OnAsyncMethodEnd<TTarget, TReturn>(TTarget nullInstance,
 
         var isHttpProxying = !string.IsNullOrEmpty(capabilities.GetCapabilityState("HttpUri"));
         var requiresRouteParameters = !string.IsNullOrEmpty(capabilities.GetCapabilityState("RequiresRouteParameters"));
-        var useNullableHeaders = !string.IsNullOrEmpty(capabilities.GetCapabilityState("UseNullableValueDictionaryForHttp"));
 
-        // When proxying, this method returns a singleton value that we must not update, so we create a new one
-        // If we're not proxying, we can safely inject the context into the provided gRPC request
-        var typedData = isHttpProxying && !requiresRouteParameters
-                            ? TypedDataHelper<TReturn>.CreateTypedData()
-                            : returnValue.DuckCast<ITypedData>();
+        // When HTTP proxying is enabled (ASP.NET Core integration), the host will make an actual HTTP call
+        // to the worker process. The HTTP client instrumentation will automatically create a span for this call
+        // and propagate context via HTTP headers. We should NOT inject context into the gRPC message in this case,
+        // as it would cause worker spans to be incorrectly parented to the Azure Functions host span instead of
+        // the HTTP client span. See APMSVLS-58 and docs/development/AzureFunctions.md for details.
+        if (isHttpProxying && !requiresRouteParameters)
+        {
+            // Let HTTP client instrumentation handle context propagation
+            return returnValue;
+        }
+
+        // For non-HTTP-proxying scenarios (e.g., timer triggers, non-ASP.NET Core HTTP triggers),
+        // we need to inject context into the gRPC message
+        if (tracer.ActiveScope is not Scope { Span: var span })
+        {
+            return returnValue;
+        }
+
+        var useNullableHeaders = !string.IsNullOrEmpty(capabilities.GetCapabilityState("UseNullableValueDictionaryForHttp"));
+        var typedData = returnValue.DuckCast<ITypedData>();
 
         var context = new PropagationContext(span.Context, Baggage.Current);
         tracer.TracerManager.SpanContextPropagator.Inject(context, new RpcHttpHeadersCollection<TTarget>(typedData.Http, useNullableHeaders));
 
-        // Get the "real" value back out, whether it's the one we were provided or the new one we created
-        return (TReturn)typedData.Instance!;
+        return returnValue;
     }
 }
 #endif