Converge sync and async resources

[dyladan]

Fixes: #3582

This PR makes it so that any resource detector can detect sync and async resources, returning both in a single resource object.

• Internally, the resource now stores all key/value pairs in a list. This means the override order comes from the order of detection, not the order of when the promises are resolved. Rejected promises are skipped. This should make the order of resource detection significantly more obvious to end users. It also paves the way for entities which explicitly require detection priority to be defined by the order in which entity detectors are configured.
• Resource detectors now return plain objects instead of new Resource instances. This should improve type compatibility in the future.
• Detected resource interface contains an optional attributes key, which all attributes are nested under. This will make it easier to extend for entities in the future by adding a new key to the object.

To be done in follow-up:

• [Resource] remove class and namespace export #5358
• [v2] Remove unstable resource detectors from resource package #5364

[pichlermarc]

Thank you for working on this 🙂
A quick preliminary review - I'll have a closer look at the implementation details next week :)

[codecov]

Codecov Report

Attention: Patch coverage is 85.16484% with 27 lines in your changes missing coverage. Please review.

Project coverage is 94.78%. Comparing base (bdc0e3a) to head (cd8a8f1).
Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
...lemetry-resources/src/detectors/BrowserDetector.ts	43.75%	9 Missing ⚠️
...ntelemetry-browser-detector/src/BrowserDetector.ts	0.00%	4 Missing ⚠️
...entelemetry-resources/src/detectors/EnvDetector.ts	93.87%	3 Missing ⚠️
...es/opentelemetry-resources/src/detect-resources.ts	80.00%	2 Missing ⚠️
...ntelemetry-resources/src/detectors/NoopDetector.ts	33.33%	2 Missing ⚠️
...tectors/platform/node/ServiceInstanceIdDetector.ts	33.33%	2 Missing ⚠️
packages/opentelemetry-resources/src/Resource.ts	97.87%	1 Missing ⚠️
...tors/platform/browser/ServiceInstanceIdDetector.ts	0.00%	1 Missing ⚠️
...ces/src/detectors/platform/node/ProcessDetector.ts	91.66%	1 Missing ⚠️
...rs/platform/node/machine-id/getMachineId-darwin.ts	66.66%	1 Missing ⚠️
... and 1 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5350      +/-   ##
==========================================
+ Coverage   94.62%   94.78%   +0.15%     
==========================================
  Files         318      311       -7     
  Lines        8038     7974      -64     
  Branches     1687     1678       -9     
==========================================
- Hits         7606     7558      -48     
+ Misses        432      416      -16     

Files with missing lines	Coverage Δ
...imental/packages/opentelemetry-sdk-node/src/sdk.ts	96.01% <100.00%> (ø)
...ental/packages/opentelemetry-sdk-node/src/utils.ts	88.23% <100.00%> (ø)
...ges/opentelemetry-resources/src/detectors/index.ts	100.00% <100.00%> (ø)
...elemetry-resources/src/detectors/platform/index.ts	100.00% <100.00%> (ø)
...ources/src/detectors/platform/node/HostDetector.ts	100.00% <100.00%> (ø)
...esources/src/detectors/platform/node/OSDetector.ts	100.00% <100.00%> (ø)
...try-resources/src/detectors/platform/node/index.ts	100.00% <100.00%> (ø)
...ctors/platform/node/machine-id/getMachineId-bsd.ts	100.00% <100.00%> (ø)
...ors/platform/node/machine-id/getMachineId-linux.ts	100.00% <100.00%> (ø)
...ctors/platform/node/machine-id/getMachineId-win.ts	93.33% <100.00%> (ø)
... and 12 more

... and 5 files with indirect coverage changes

[chancancode]

Take it with an unhealthy amount of salt, but other than the suggestions I left (feel free to make your own judgment call), it looks good to me!

[trentm]

I think this LGTM.

I asked a Q at #5358 (comment)
I'm not totally clear on what the user's experience with resources (usage with the SDK I mean) will be after these changes at #5358, especially when Entities come along.

[trentm]

Might be nice to ahve a comment here that resource is first here because (a) the implementation is "first one wins" and (b) the spec says:

https://opentelemetry.io/docs/specs/otel/resource/sdk/#merge

If a key exists on both the old and updating resource, the value of the updating resource MUST be picked (even if the updated value is empty).

[dyladan]

I'll add a comment, but does this implementation convey intent better to you?

    return Resource.FromAttributeList(
      [...this.getRawAttributes(), ...resource.getRawAttributes()].reverse()
    );

advantages:

• More explicit intent
• reversing both arrays guards against arrays with duplicate entries (unlikely/impossible but /shrug)

disadvantages:

• slightly less efficient

[dyladan]

Another possibility would be to change the impl of FromAttributeList to have the opposite order semantic.

edit: actually the first-wins semantic comes from the attributes getter, so that's what would have to change.

[david-luna]

is it possible that we get duplicated attributes if both resources define the same one?

[dyladan]

they can be duplicated in the list but the attributes getter would ignore duplicates when they are retrieved and memoized

[david-luna]

maybe I missed some context. We removed the call to waitForAsyncAttributes in this function and it seems no component is calling it. So some attributes may stay as promises within the resource instance.

[dyladan]

the wait for async attributes happens in the export pipeline (i think specifically in the processor). The resource no longer needs to be awaited for the new list-based merge logic, which was the original reason for awaiting in the detection.

[david-luna]

thanks for the explanation :)