Identify the cause of transitive failures in screenshot tests

[riccardobl]

Identify the cause of transitive failures in screenshot tests and fix them, if unfixable (ie. caused by underlying software stack) make the screenshot tests retry 3 times before marking them failed in the CI.

An example of a PR with a transitive failure is #2963

[jaime-jmebot]

I dug into the transient failures and they are pixel-comparison noise rather than a rendering regression. Opened #2965 with the fix.

What the evidence shows

• The two recent Android screenshot failures happened on unrelated commits (Add Android Game-Mode API listener support (#1995) #2961 and BitmapFont: drop the unused arrayBased flag and avoid LinkedList.get(int) traversals #2963) and always on the same test, TestExplosionEffect: "Generated images is different from committed image". The run in between passed.
• The changed image pulled off the device is 442,598 bytes for a 1280x800 frame, against a 442,536 byte reference — only a handful of pixels apart.
• The comparison used to be all-or-nothing: the first pixel differing by more than 3/255 failed the whole test, and the report did not say by how much.

Why the retries could not help

That difference is a property of the machine that rendered it. CI renders with software renderers (Mesa on desktop, the emulator's GLES renderer on Android) whose rounding varies between runners, so re-running on the same runner reproduces the same mismatch — which is why all 3 attempts failed while another job passed the identical code. Retrying cannot change the host it runs on. The retry loops added in #2863 stay, they are what saves the desktop/ANGLE jobs when the display server or a JVM dies, but they were never going to fix this particular failure.

The fix in #2965

• New ImageDifference measures the whole difference instead of stopping at the first bad pixel, and treats a small number of out-of-tolerance pixels (0.02% of the image, at least 10 pixels) as renderer noise. A change to what is actually drawn moves far more pixels than that and still fails.
• Failures now report the measurement, e.g. 5 of 10000 pixels differ by more than 3 (at most 10 tolerated), largest single channel difference 255, so a real change can be told from a hiccup without downloading artifacts.
• New ImageDifferenceTest plus a README section on the tolerance; the CI workflows were left untouched.