Trace Ids Are Occasionally Lost

[austin-tcetra]

Describe the bug
When calling a WCF service, if the method signature uses Task<*>, the trace id is often lost.

To Reproduce

1. Given the below runtime environment, our apps dropped trace ids associated with its logs.
2. Trace Ids are not lost when the WCF method signature does NOT return a Task. (It worked when our method signature returned a string instead of Task<string>)
3. When the method signature includes Task<string> (or any other type of task). Trace ids are generally lost. (It's not 100% of the time, we suspect a race condition).
4. The signature or manner of the client did not change the loss of trace id. (We could await, or call in an async method, or call it as a synchronous call, etc).
5. AfterReceiveRequest would always have a trace_id
6. Inside the message body, we could get the trace_id from DD
7. BeforeSendReply would not have a trace_id

Expected behavior
We expect to see a trace_id in the DD logs, as well as in the BeforeSendReply method.

Runtime environment (please complete the following information):

• Instrumentation mode: datadog-dotnet-apm-2.47.0-x64.msi etc,
• Tracer version: 2.47.0, 2.49.0, 2.56.0
• OS: Windows Server 2022 Datacenter, Version 10.0.20348 Build 20348
• CLR: .NET Framework 4.8

Additional context
We implemented a "workaround" where we stuff the trace_id into state and in our logs override the DD fields (trace_id and span_id) from state. We're assuming this is a threading issue or race condition.