fix(core): avoid leaking Node.js types via otperformance

[pichlermarc]

Which problem is this PR solving?

See #5916

This is the likely more controversial fix (see #5986 for Part I). otperformance exported from @opentelemetry/core is leaking Node.js' types even when the project it is used in is not Node.js-based.

The problem here is that the type-defintion is overly broad for what it represents (has Node.js extensions that don't exist in the browser). In our code-base essentially only now() and timeOrigin are used without casting the type. My proposal is to use { now(): number; readonly timeOrigin: number} as a replacement. This will narrow down the type to a safe minimal API, but it will technically be breaking.

I assume though, that since otperformance

• is likely not commonly used by end-users and,
• the incorrect type can lead to run-time issues,

technically breaking folks that use it in that way is - if anything - a heads-up that there may be a bug in their code too.

In the past, I've occasionally mentioned SemVer TS (a TypeScript-specific variant of SemVer) as the basis for some of my decisions as I feel like it explains many TypeScript versioning caveats very well. It seems to support the sentiment that this sort of change would be acceptable too:

[...]

• If an interface is defined as having a property which is not part of the public API of the runtime object, or if an interface is defined as missing a property which the public API of the runtime object does have, this is a bug.

As with runtime bugs, authors are free to fix type bugs in a patch release. As with runtime code, this may break consumers who were relying on the buggy behavior. However, as with runtime bugs, this is well-understood to be part of the sociotechnical contract of semantic versioning.
[...]

The spec then continues with:

If a given type bug has existed for long enough, an author may choose to treat it as "intimate API" and change the runtime behavior to match the types rather than vice versa.

Changing the runtime behavior to match the types would in our case mean that we'll have to essentially polyfill any Node.js extensions there are, which IMO may just lead to more type-level bugs down the line that need fixing.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.18%. Comparing base (8e9b8bb) to head (133d8e6).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@ ## main #5987 +/- ## ========================================== + Coverage 95.17% 95.18% +0.01%  ========================================== Files 316 315 -1 Lines 8521 8520 -1 Branches 1763 1763 ========================================== Hits 8110 8110 + Misses 411 410 -1 

Files with missing lines	Coverage Δ
...pentelemetry-core/src/platform/node/performance.ts	100.00% <100.00%> (ø)

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

[david-luna]

I've checked places where otperformance is used like @opentelemetry/instrumentation-document-load and the code is already casting the type to the browser API.

const performanceNavigationTiming = ( otperformance as unknown as Performance ).getEntriesByType?.('navigation')[0] as PerformanceEntries;

Not sure how many packages might use this export directly but the remediation for any type issue is pretty straight forward. Browser instrumentations are already doing it.

[pichlermarc]

Unlinked #5916 to avoid closing it when I merge this.
We still need #5986 to fix this bug.