Feature/master/utils lite lambda trace

[RanVaknin]

This PR adds:

1. New utils-lite code package that provides SdkInternalThreadLocal, a wrapper around threadLocal.
2. Support for trace id propagation using the new utils-lite class

Background

Previously, we implemented trace ID propagation using SLF4J's MDC in PR #6363, but this was
reverted because the MDC interface exists but the implementation is not provided by the SDK, Lambda runtime, or X-Ray SDK.

Solution

Added a small utils-lite utility class that provides thread local key value storage using ThreadLocal<Map<String, String>>. For this case, it allows the Lambda Runtime Interface Client, AWS SDK, and X-Ray SDK to share trace context via this one package, but can extended to other use cases.

Example:

SdkInternalThreadLocal.put("some-value", foo);
String traceId = SdkInternalThreadLocal.get("some-value");
SdkInternalThreadLocal.remove("some-value");
SdkInternalThreadLocal.clear();

[joviegas]

Is this a requirement ?
Why is this test required ?

[RanVaknin]

This was following @zoewangg suggestion to add a manual check to make sure we don't add classes to this package unintentionally. The sole purpose of this package as of now is to add this wrapper. If we want to expand this in the future, this presents another checkpoint.

[joviegas]

I see SdkInternalThreadLocal we do a put and we never call remove/clear thus if TRACE_ID is unique then the map in SdkInternalThreadLocal will keep growing . How do we clear/remove CONCURRENT_TRACE_ID_KEY for request that are compete

[RanVaknin]

If a thread goes back to thread pool, and a fresh request is being fired from the Lambda Runtime Client interface, it will contain a brand new traceID stored under the same key on the map so it will overwrite itself.

If the thread is killed, then when a new thread is being spun up, a clean map is created.

[joviegas]

Since we are using ThreadLocal can we confirm if this can come across virtual thread ?
As in if customer makes call on a virtual thread , if the impact has been investigated ?

[joviegas]

Also I was thinking about this case where client is running on host where SdkInternalThreadLocal was not cleared/not-used

1. beforeExecution():
   - SdkInternalThreadLocal.get(CONCURRENT_TRACE_ID_KEY) → null (first time)
   - Creates HashMap for Thread-1 (empty)

Now lets imagine the user is creating new request for every thread as below

for (int i = 0; i < 1_000_000; i++) {
    new Thread(() -> {
        AmazonS3 client = AmazonS3ClientBuilder.standard().build();
        client.getObject(...);  // Creates HashMap for this thread
        client.shutdown();
        // Thread dies, but not sure what will happen to the above empty HashMap instantaited
    }).start();
}

Result: 1,000,000 HashMaps created ? Can we please confirm this will not cause any leak of empty hash maps ?

[RanVaknin]

Great call out. I didnt think about this. I changed it so that the hashmap only gets initialized when .put() is being called (initially called by lambda RIC)

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE