fix(otel): support tag flattening [AIT-9352]

[mabdinur]

Ensures otel tags/attribute values with the type List, Tuple and/or set are flattened. This operation is already done by the Datadog UI when displaying tags. However we should also do this in the tracer to better align with other languages.

The flattening logic must follow this spec:

Array values must decay into as many keys as there are entries in the array. The keys must be mapped by concatenating the outer and inner key values together, recursively, separated by a dot. In pseudo-code:
fn addArrayAttribute(key, array):
for (subkey, value) in array:
addScalarOrArrayAttribute(key + "." + subkey, value)
Example: Given attributes {"key": [[1,2], ["3", "4"]]}, we will have {"key.0.0": "1", "key.0.1": 2, "key.1.0": 3, "key.1.1":4}.

Checklist

• Change(s) are motivated and described in the PR description.
• Testing strategy is described if automated tests are not included in the PR.
• Risk is outlined (performance impact, potential for breakage, maintainability, etc).
• Change is maintainable (easy to change, telemetry, documentation).
• Library release note guidelines are followed. If no release note is required, add label changelog/no-changelog.
• Documentation is included (in-code, generated user docs, public corp docs).
• Backport labels are set (if applicable)

Reviewer Checklist

• Title is accurate.
• No unnecessary changes are introduced.
• Description motivates each change.
• Avoids breaking API changes unless absolutely necessary.
• Testing strategy adequately addresses listed risk(s).
• Change is maintainable (easy to change, telemetry, documentation).
• Release note makes sense to a user of the library.
• Reviewer has explicitly acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment.
• Backport labels are set in a manner that is consistent with the release branch maintenance policy
• If this PR touches code that signs or publishes builds or packages, or handles credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
• This PR doesn't touch any of that.

[emmettbutler]

I'll wait to do a proper review until CI is passing. Let me know if you'd like detailed feedback before then.

[emmettbutler]

The change looks great. What do you think is causing the performance regression?

[mabdinur]

The change looks great. What do you think is causing the performance regression?

We attempt to flatten key value pairs that do not need flattening. Although we exit early in this scenario it still results in an extra function call and creates some new objects. I'll clean it up

[emmettbutler]

Nice! I see from the benchmarking platform (CI pipeline ID
26358953) that you solved the performance regression.

[github-actions]

The backport to 2.4 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.4 2.4
# Navigate to the new working tree
cd .worktrees/backport-2.4
# Create a new branch
git switch --create backport-8042-to-2.4
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 7c75365cef4c9d9c8fa9d3fe78f383ce49362889
# Push it to GitHub
git push --set-upstream origin backport-8042-to-2.4
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.4

Then, create a pull request where the base branch is 2.4 and the compare/head branch is backport-8042-to-2.4.