Bug 1686295 - Flip the order of two time measurement calls in telemet…

…ry to provide actual guarantees to callers. r=chutten

See the comment in the code for the rationale. Having it in the other order
(before this patch) caused a but real rare intermittent on Linux and macOS, the
two OSes where this is used and the clock has a high enough resolution. This
happened when the first call was made before a millisecond mark and the second
one after, with the same time source: machines on treeherder don't suspend, the
numbers should be equal, but rarely the time excluding suspend was longer by 1ms
compared to the time including suspend.

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

toolkit/components/telemetry/pings/TelemetrySession.jsm

@@ -751,14 +751,21 @@ var Impl = {
       const isMobile = AppConstants.platform == "android";
       const isSubsession = isMobile ? false : !this._isClassicReason(reason);
 
-      Telemetry.scalarSet(
-        "browser.engagement.session_time_including_suspend",
-        Telemetry.msSinceProcessStartIncludingSuspend()
-      );
+      // The order of the next two msSinceProcessStart* calls is somewhat
+      // important. In theory, `session_time_including_suspend` is supposed to
+      // ALWAYS be lower or equal than `session_time_excluding_suspend` (because
+      // the former is a temporal superset of the latter). When a device has not
+      // been suspended since boot, we want the previous property to hold,
+      // regardless of the delay during or between the two
+      // `msSinceProcessStart*` calls.
       Telemetry.scalarSet(
         "browser.engagement.session_time_excluding_suspend",
         Telemetry.msSinceProcessStartExcludingSuspend()
       );
+      Telemetry.scalarSet(
+        "browser.engagement.session_time_including_suspend",
+        Telemetry.msSinceProcessStartIncludingSuspend()
+      );
 
       if (isMobile) {
         clearSubsession = false;