fix(sdk-metrics): use default Resource to comply with semconv

[pichlermarc]

Which problem is this PR solving?

Currently the Metrics SDK does not comply with the resource semantic conventions (see #3410).

This PR changes MeterProvider to use Resource.default() (which already contains the required/recommended attributes), which is then merged with the user-provided resource.

Fixes #3410

Type of change

Please delete options that are not relevant.

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

How Has This Been Tested?

• Adapted existing unit tests
• Manual testing

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[codecov]

Codecov Report

Merging #3411 (ee3fe3a) into main (1b7246a) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3411      +/-   ##
==========================================
- Coverage   93.26%   93.24%   -0.02%     
==========================================
  Files         247      247              
  Lines        7347     7348       +1     
  Branches     1512     1512              
==========================================
  Hits         6852     6852              
- Misses        495      496       +1     

Impacted Files	Coverage Δ
packages/sdk-metrics/src/MeterProvider.ts	100.00% <100.00%> (ø)
...-trace-base/src/platform/node/RandomIdGenerator.ts	87.50% <0.00%> (-6.25%)	⬇️

[dyladan]

@open-telemetry/javascript-maintainers should this be backported? It will result in additional resource attributes usually and users may not expect telemetry to be different in a patch upgrade

[legendecas]

LGTM % nits on the changelog entry.

[legendecas]

@dyladan should this be backported? It will result in additional resource attributes usually and users may not expect telemetry to be different in a patch upgrade

What do you suggest on "backport"? AFAICT, we don't have multiple release lines to be maintained.

[dyladan]

@dyladan should this be backported? It will result in additional resource attributes usually and users may not expect telemetry to be different in a patch upgrade

What do you suggest on "backport"? AFAICT, we don't have multiple release lines to be maintained.

We typically don't backport but i've been trying to think about a release strategy which can put us on a more predictable release cadence without blocking bugs for a long time. We've been releasing basically when we felt like it, which has been a pain point for users waiting on fixes or features. Let's discuss in another issue though. I don't think this bug is a good candidate to test a backport process anyway