PHP 8.0.30 legs: segfaults (exit 139) in FeedsTest and status 0 from the demo's built-in server #9

What happens

On the PHP 8.0 legs of the Tests workflow (PHP 8.0.30, from
shivammathur/setup-php), two failures come and go. They are not tied to a
commit, and the same commit passes on a rerun.

1. PHP crashes (exit 139) in FeedsTest

FAIL  FeedsTest > RSF01-03 deciding: deny 403 right after the deny list, check = the browser check, ...
      PHP ended with a crash (exit 139, a segfault) -- during this test, before it could report

Sometimes the test is FeedsTest > RSF01-03 a list too old is not used -- and the settings are built again when it grows too old.
It is always FeedsTest, and it is only seen on 8.0: on PHP 8.0 + APCu, and
on the single-file legs PHP 8.0 (file store), single file and
PHP 8.0 + APCu, single file.

• https://github.com/cjw-network/request-shield/actions/runs/37919387109/job/113783443078 (PHP 8.0 + APCu)
• https://github.com/cjw-network/request-shield/actions/runs/37915774773/job/113771527802 (PHP 8.0 + APCu)
• https://github.com/cjw-network/request-shield/actions/runs/37914273763/job/113766611484 (PHP 8.0 + APCu)
• https://github.com/cjw-network/request-shield/actions/runs/37786747308/job/113343726228 (PHP 8.0 + APCu)
• https://github.com/cjw-network/request-shield/actions/runs/37782901569/job/113330328338 (PHP 8.0 + APCu)
• https://github.com/cjw-network/request-shield/actions/runs/37777009006/job/113310369800 (PHP 8.0 (file store), single file)
• https://github.com/cjw-network/request-shield/actions/runs/37905940761/job/113739337500 (PHP 8.0 (file store), single file)
• https://github.com/se7enxweb/request-shield/actions/runs/38120981093/job/114415779220 (PHP 8.0 + APCu, single file, the fork)

2. The demo's built-in server answers with status 0

FAIL  DemoTest > RSF03-01 the demo's group "Budgets and pace": ...
      row 14.1: its "See the path" link opens the rules page: expected 200, got 0

A different row each time. It happens on the 8.0 legs, where DemoTest
runs the demo in php -S:

• https://github.com/cjw-network/request-shield/actions/runs/37777009006/job/113310369713
• https://github.com/cjw-network/request-shield/actions/runs/37765513436/job/113272145632
• https://github.com/cjw-network/request-shield/actions/runs/37762043051/job/113260634143
• https://github.com/cjw-network/request-shield/actions/runs/37759124969/job/113251022183
• https://github.com/cjw-network/request-shield/actions/runs/37757597049/job/113245968924
• https://github.com/cjw-network/request-shield/actions/runs/37742365254/job/113195852164
• https://github.com/se7enxweb/request-shield/actions/runs/38122519080/job/114420039565 (PHP 8.0 (file store), the fork)

Related, also on PHP 8.0 + APCu: the row check "the page's own answer
agrees: null" (row 2.1 in
https://github.com/cjw-network/request-shield/actions/runs/37892135923/job/113695261511,
row 5.1 and row 9.1 in runs 37791520658 and 37790155704). This looks like the
same thing: the row's request got no answer.

What we know

• Neither has been seen on 8.1 to 8.5, and neither happens locally in
  repeated runs (8.5.11).
• 8.0 has been out of security support since November 2023, and 8.0.30 is its
  last release. A crash fixed in 8.1 will not be fixed in 8.0.
• A status 0 alone does not show whether the demo's server crashed. Updated: A demo test whose request gets no answer says whether the demo's server ended, and how #8 makes
  withDemo() say so when the server has ended (signal 11 or an exit code).
  The next failure will then tell the two cases apart.

What could be done

1. Wait for the next status 0 with Updated: A demo test whose request gets no answer says whether the demo's server ended, and how #8 merged. If it says "signal 11", both
   failures are the same 8.0 crash.
2. Then either:
   • mark these tests as skipped on PHP 8.0 (PHP_VERSION_ID < 80100) with a
     note pointing here, while the library itself still supports 8.0; or
   • retry such a test once on 8.0 when PHP ended with signal 11, and fail
     only when it happens twice; or
   • get a backtrace on one leg (ulimit -c unlimited and gdb in the job,
     or USE_ZEND_ALLOC=0 to see if it is a memory manager issue), in case
     the crash comes from something the library does that a newer PHP only
     happens to tolerate.

Until then, a red 8.0 leg with one of these two messages is the PHP 8.0
crash, not a regression in the commit under test.