feat(opentelemetry-sdk-node): use declarative config for resource attributes

[maryliag]

Start to use configuration package on sdk-node.
For now is a basic usage, just to get feedback on implementation. Things should work normally without changes.

Using values for sdk disable, log level, and resource attributes from config model

[codecov]

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 95.23%. Comparing base (daa3fe2) to head (8d0faf3).
⚠️ Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
...ental/packages/opentelemetry-sdk-node/src/utils.ts	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6044      +/-   ##
==========================================
+ Coverage   95.21%   95.23%   +0.01%     
==========================================
  Files         316      317       +1     
  Lines        9389     9395       +6     
  Branches     2167     2166       -1     
==========================================
+ Hits         8940     8947       +7     
+ Misses        449      448       -1     

Files with missing lines	Coverage Δ
...imental/packages/opentelemetry-sdk-node/src/sdk.ts	96.56% <100.00%> (+0.03%)	⬆️
...tal/packages/opentelemetry-sdk-node/src/semconv.ts	100.00% <ø> (ø)
...ental/packages/opentelemetry-sdk-node/src/utils.ts	93.02% <75.00%> (+0.77%)	⬆️

🚀 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]

quick review - I did not have a detailed look at this PR yet.

[JamieDanielson]

This is looking good after the changes we talked about... one question I had around our checking for a valid config file that may have unexpected / unacceptable consequences if someone accidentally puts an invalid value for their config file env var.

[maryliag]

@JamieDanielson the PR with the changes on error -> warning got merged, so PTAL in this one

[JamieDanielson]

Exciting!

[JamieDanielson]

Let's make sure we update the default value before merging this in.

[maryliag]

I marked the discussion as resolved, because they're being discussed in the other PRs.

PRs ins question are #6130 and #6131

[JamieDanielson]

We had some further discussion during the SIG meeting about whether we want a separate, parallel path in sdk-node that utilizes the config file (instead of implementing the behavior in the current class).

While this will result in some code duplication in the short-term, it also provides a clean slate to implement a newer, better designed configuration that uses functions to initialize the SDK instead of a class, allowing more flexibility in our implementation, and later we can deprecate the NodeSDK class when we are ready. This would also allow us to move quickly with minimal risk because it is essentially feature flagged; we could even put it in an experimental entrypoint.

There is a concern about confusion to end users - will it be obvious which setup path they should take? - but the tradeoff may be worth it, especially if we keep it in an experimental entrypoint and/or add lots of code comments around the experimental path.

[maryliag]

closing this as we will use a different approach on #6145, starting with a new function