[SVLS-4780] upstream Java sns and sqs refactor

[joeyzhao2018]

What does this PR do?

Extract trace context in SNS and SQS cases where the upstream service is instrumented by dd-trace-java In short,

1. For Java => SNS => Lambda, the env: _X_AMZN_TRACE_ID has the dd trace id but not the correct parent id. We will still use it here.
2. For Java => SQS => Lambda or Java => SNS => SQS => Lambda case, AWS propagate the trace context in the json payload attributes.

Longer version:

Testing Guidelines

• Unittests added
• Integration tests added https://github.com/DataDog/dd-trace-x-lambda-examples/blob/main/lib/wip-cases/sns-java-checks-nested-stack.ts
• Manually tested (You can see the parenting issue causing a white space between spans) Single Message Publish

Batch Publish

Additional Notes

Types of Changes

• [ ] Bug fix
• [x] New feature
• [ ] Breaking change
• [ ] Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• [ ] This PR's description is comprehensive
• [ ] This PR contains breaking changes that are documented in the description
• [ ] This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• [ ] This PR impacts documentation, and it has been updated (or a ticket has been logged)
• [ ] This PR's changes are covered by the automated tests
• [ ] This PR collects user input/sensitive content into Datadog
• [ ] This PR passes the integration tests (ask a Datadog member to run the tests)

[joeyzhao2018]

Left some comments.

@duncanista 's comments made me take a closer look at the way i added debug logs. And after some thoughts I think it's best to use just one static string as the parameter and removed extra logging of the event payload or tracecontext. This is to avoid any extra memory allocation and keep the code cleaner. Based on my on-call experience, we usually get the event payload from other logs.