increase sleep duration in measure_associated... WPT.

Over two weeks, this test intermittently failed on Firefox in 1/17 runs. After
reading the timestamp [precision reduction code], the cause of the failure
appears to be that we're not sleeping long enough. We clamp the value (i.e.
discard sub-millisecond precision) and randomly round up to the next millisecond
value via the midpoint & clampedAndJittered code. In the worst case, this will
cause values 1.999ms apart to be rounded to the same value, e.g. 10ms and
11.999ms round to 11ms. In theory, we need to sleep at least 2ms but we've been
sleeping 1ms.

[precision reduction code]: https://searchfox.org/mozilla-central/rev/31368c7795f44b7a15531d6c5e52dc97f82cf2d5/toolkit/components/resistfingerprinting/nsRFPService.cpp#413-428

Differential Revision: https://phabricator.services.mozilla.com/D156988

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1772416
gecko-commit: 61831cfe799a76e3bf5c342ab22ce42ea2faab6f
gecko-reviewers: sefeng

user-timing/measure_associated_with_navigation_timing.html

@@ -38,8 +38,10 @@
     // However, this assertion will fail if the test executes fast enough such that the marks occur
     // at the same clock time. This is more likely in browsers such as Firefox that reduce the
     // precision of the clock exposed through this API to mitigate timing attacks. To mitigate the
-    // test failure, we sleep.
-    sleep_milliseconds(1);
+    // test failure, we sleep. Firefox may round timestamps to the nearest millisecond in either
+    // direction - e.g. 10ms & 11.999ms may both round to 11ms - so we need to sleep at least 2ms to
+    // avoid test failures. To be safe, we sleep 3ms.
+    sleep_milliseconds(3);
 
     // Following cases test for scenarios that measure names are tied twice.
     mark_names.forEach(function(name) {