test: Added assertSegmentDuration and missing segment duration tests

[amychisholm03]

Description

WIP: Not ready for full review yet, just testing CI.

As we migrate our instrumentation to use the tracing channel subscribers, we need a way to be able to check if our segment durations are expected (e.g. not ending immediately). However, previous attempts have been extremely flaky because our CI has much more constrained environments vs our PCs running locally.

This PR adds a new custom assertion, assertSegmentDuration and adds it to tests whose packages we have migrated over and need segment duration timing tests (packages like mysql2 with "easy" way to assert time like sleep(2) were excluded). In an attempt to combat flakiness, getDefaultThreshold in assert-segment-duration.js comes up with a percentage threshold (as a float) based on the number of CPU cores available. The numbers are basically arbitrary but seem okay enough to consistently pass.

Some tests, like memcached.test.js, are really really flaky so they have a high threshold supplied instead of using the default.

How to Test

npm run versioned:major

Related Issues

Closes #3862

[bizob2828]

i see the CI failed and the actual duration vs record durations seem off like our timing is wrong

[amychisholm03]

i see the CI failed and the actual duration vs record durations seem off like our timing is wrong

Yeah, there are some large time differences. However, the failures are different packages every time, so I don't think it has to deal with how we are timing the actualTime, but just general flakiness for some reason.