fix(otlp-transformer): correctly handle Uint8Array attribute values when serializing to JSON

[pichlermarc]

Which problem is this PR solving?

Fixes #6190

Uint8Arrays (including Buffers) are currently not handled properly when they get exported as part of a log record body or attribute value. The incorrect handling results in bytesValue containing an array of numbers instead of the data as a base64-encoded string - this causes the collector to reject the whole request.

Semi-related changes:

• We had an intermediate step that allowed options to be passed, from which a Encoder object was created. In the past, this was public API; nowadays however, it's an implementation detail. As it was getting difficult to track which of the four options apply to which format in testing, I opted to remove this intermediate options step and pass the Encoder directly.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Existing tests
• Added tests

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.48%. Comparing base (903739c) to head (2ce4f0f).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6348      +/-   ##
==========================================
- Coverage   95.68%   95.48%   -0.21%     
==========================================
  Files         313      363      +50     
  Lines        9667    11564    +1897     
  Branches     2226     2669     +443     
==========================================
+ Hits         9250    11042    +1792     
- Misses        417      522     +105     

Files with missing lines	Coverage Δ
...l/packages/otlp-transformer/src/common/internal.ts	100.00% <100.00%> (ø)
...ntal/packages/otlp-transformer/src/common/utils.ts	100.00% <100.00%> (ø)
...tal/packages/otlp-transformer/src/logs/internal.ts	100.00% <100.00%> (ø)
...al/packages/otlp-transformer/src/logs/json/logs.ts	100.00% <100.00%> (ø)
...ackages/otlp-transformer/src/logs/protobuf/logs.ts	100.00% <100.00%> (ø)
.../packages/otlp-transformer/src/metrics/internal.ts	100.00% <100.00%> (ø)
...kages/otlp-transformer/src/metrics/json/metrics.ts	100.00% <100.00%> (ø)
...s/otlp-transformer/src/metrics/protobuf/metrics.ts	100.00% <100.00%> (ø)
...al/packages/otlp-transformer/src/trace/internal.ts	98.55% <100.00%> (-0.05%)	⬇️
.../packages/otlp-transformer/src/trace/json/trace.ts	100.00% <100.00%> (ø)
... and 1 more

... and 60 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pichlermarc]

note: something was wrong with the coverage upload, so I pushed a commit so that the browser/webworker tests also publish the results to coverage/ instead of .nyc_output/ - that resolved the issue.

[raphael-theriault-swi]

Much prefer this approach to the options !

[raphael-theriault-swi]

Is this still used anywhere after the changes ?

[david-luna]

it is used by createExpectedSpanJson function in test/trace.test.ts to create the expected spans within the test. Tests are using different combinations of the options so (without knowing much) I guess is better to keep it. We could move the type to the test file.

[pichlermarc]

yep, that's the reason why I kept it for now. Once I get to working on the custom proto serializer, I'm hoping that I can further simplify the tests and get rid of that too.

[david-luna]

Thanks for working on this @pichlermarc :)