Bug 1922836 [wpt PR 48478] - compute pressure: Rewrite rate obfuscati…

…on web tests as unit tests, a=testonly

Automatic update from web-platform-tests
compute pressure: Rewrite rate obfuscation web tests as unit tests

These tests have been flaky since they have been rewritten to use
WebDriver (bug 347031400). https://crrev.com/c/5898989 added them to
SlowTests, but that did not work: contrary to what I expected, marking a
test as long in WPT's metadata and adding it to SlowTests are
idempotent, not cumulative operations (i.e. I thought adding a test to
SlowTests would increase the timeout even more, but it's just a no-op if
the test is already marked as long).

However, after investigating it further I believe this is not just a
timeout problem: these tests cannot work anymore by definition. The idea
of these tests is to send a number of updates and verify that:

* Sending a number of updates smaller than the spec-defined threshold to
  trigger the mitigations causes the difference between
  PressureRecord.time in subsequent updates to be smaller than the
  penalty time.

* Sending a number of updates greater than the spec-defined threshold
  does trigger the mitigation and cause update N within a spec-defined
  range to be sent with an implementation-defined delay.

In all cases, we need to send an update to WebDriver and verify that
PressureObserver has received it before sending the next one.
Consequently, the time it takes between sending and receiving updates is
actually outside the test's control: busy bots (such as the mac-rel and
win-rel ones) can simply cause the web test to WebDriver or the
WebDriver to browser process communication to take arbitrarily long,
leading to:

* Measured time between updates that should not trigger a penalty still
  taking longer than allowed because the system took too long to deliver
  the update_virtual_pressure_source() call. This causes the "not
  triggered" test to fail and leads to false positives in the
  "triggered" test.

* Calls to update_virtual_pressure_source() taking too long to be on the
  browser side so that and/or too few updates being sent from the
  browser side while waiting under penalty so that the difference
  between the pre-penalty update's timestamp and the
  update-under-penalty's timestamp ends up being less than the minimum
  penalty time. This makes the "triggered" test never flip the
  |gotPenalty| flag to true.

This was not a problem in the past because the MojoJS-based tests were
restricted to Blink.

The only way to have full control over the timing is to use unit tests
where we can have a mock time source that we move forward as we see fit.

Bug: 370726578, 347031400
Change-Id: I9b21513c7b8e83177e7d7b091607100d0cd21c87
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5909373
Reviewed-by: Reilly Grant <reillygchromium.org>
Auto-Submit: Raphael Kubo Da Costa <raphael.kubo.da.costaintel.com>
Commit-Queue: Reilly Grant <reillygchromium.org>
Commit-Queue: Raphael Kubo Da Costa <raphael.kubo.da.costaintel.com>
Cr-Commit-Position: refs/heads/main{#1364368}

--

wpt-commits: 5861fcc529a97b8c7c29bde2c9c681f1d2ab33f1
wpt-pr: 48478

UltraBlame original commit: 438fd1d828feba79de38994759cca5d639c47eb2

testing/web-platform/tests/compute-pressure/README.md

@@ -28,111 +28,6 @@ specification
 .
 #
 #
-Notes
-to
-implementors
-compute_pressure_rate_obfuscation_mitigation_
-*
-which
-test
-the
-spec
-'
-s
-[
-rate
-obfuscation
-sections
-]
-(
-https
-:
-/
-/
-w3c
-.
-github
-.
-io
-/
-compute
--
-pressure
-/
-#
-rate
--
-obfuscation
-)
-need
-to
-send
-and
-wait
-for
-dozens
-of
-updates
-.
-Some
-tests
-may
-need
-to
-send
-over
-90
-changes
-and
-then
-wait
-up
-to
-10
-seconds
-for
-the
-next
-update
-.
-At
-1
-change
-per
-second
-this
-would
-by
-far
-exceed
-WPT
-'
-s
-timeout
-limits
-so
-implementations
-need
-to
-be
-able
-to
-dispatch
-updates
-at
-a
-higher
-rate
-than
-usual
-for
-these
-tests
-to
-pass
-.
-#
-#
 How
 to
 write