Fixed: The disk's cap test no longer depends on the clock moving to the next second

[se7enxweb]

What fails

CacheTest > RSF04-03 the disk's cap (http-cache-disk) fails now and then on
a slow leg. It was seen on PHP 8.0 + APCu, in a run of a92a37b plus the role
test fix:

https://github.com/se7enxweb/request-shield/actions/runs/38120981093/job/114415779306

FAIL  CacheTest > RSF04-03 the disk's cap (http-cache-disk): each folder holds ...
      the newest kept, the oldest gone

The same commit passed on that leg in the next run, so the failure depends on timing.

Why

The test writes answers in a loop, one after another, and after each write
sets the mtimes by hand, touch($file, time() + $n), so the older answers
stay older. Those mtimes lie in the future.

With APCu, FileCache::put() trims the folder inside put(), while it
writes the new answer, whose mtime is the real "now". Next to answers dated
time() + 1, time() + 2 …, the answer being written is the oldest one in
the folder, or as old as the first one when the clock moves to the next second
during the loop. Which answer is taken out then depends on whether a second
passed, not on the order of writing. A fast machine finishes within one
second and passes. A slow 8.0 leg sometimes does not.

The fix

Test only, in tests/CacheTest.php: the mtimes are set one second apart in
the past, touch($file, $base + $n) with $base = time() - 100. The
answer put() is writing is then always the newest, as on a real site. The
test still checks the same thing, with and without APCu: past the folder's
share, the oldest answers go and the newest stays.

Tested

• Locally (PHP 8.5.11): php tests/run.php "disk's cap" 8 times in a row
  with APCu (-d apc.enable_cli=1), and once without it: all passed.
• The fork's CI, the full matrix with this commit:
  https://github.com/se7enxweb/request-shield/actions/runs/38122519080
  The disk-cap test passes on every leg. The one failure in that run is a
  demo row on PHP 8.0 (file store) answered with status 0. That is the PHP
  8.0 built-in server and is unrelated; see Updated: A demo test whose request gets no answer says whether the demo's server ended, and how #8 and PHP 8.0.30 legs: segfaults (exit 139) in FeedsTest and status 0 from the demo's built-in server #9.