[3.0][Testing] Add HTTP smoke tests that drive a running forum

[albertlast]

Description

The integration suite from #9345 reaches the database, but never a page.
Everything between a request arriving and HTML coming back — the session, the
cookies, the theme, the templates, the permission checks — had no automated
coverage at all, and that is where the failures people actually report live.

tests/Integration/Http/ fixes that by driving a running forum over the wire.

.docker/test.sh                  # both engines, everything
.docker/test.sh --filter Posting

Requests have to be real ones: obExit(), redirectexit() and fatal*() all
end in exit, and Db::$db, ActionTrait::$obj and Theme::$loaded cannot be
reset, so a test process can carry out exactly one request in itself and no more.
tests/Support/HttpClient.php is a small browser built on the curl extension
the forum already requires, so this costs no new dependency and no Node.

The tests

• GuestPagesTest — a sweep of thirteen pages a visitor can reach, each
  asserting a real forum page came back (a fatal error in SMF is a normal page
  with an apology on it, so the status alone proves little) and that nothing was
  logged. Plus the RSS feed, a 404 for an unknown action, and registration.
• LoginTest — signing in, the cookie being issued, a wrong password being
  refused, a post with no session check being refused, and signing out.
  Worth doing over HTTP precisely because User::setMe() skips all of it.
• PostingTest — starting a topic and replying to it, then checking both are
  on the page and in the database; and that a guest cannot post.

Every one ends in assertNoErrorsLogged(). That is the point: SMF records most
of what goes wrong in log_errors rather than showing it, so a page can return a
flawless 200 while logging an undefined index on every hit.

Four things that made these harder than expected

Each is commented where it bites rather than worked around silently, because each
cost a debugging session and none of them are obvious from the symptom:

1. The first request of a new session regenerates it. SMF sets a guest login
   cookie, and Cookie::setLoginCookie() throws the session away when that value
   changes — so a security token minted on the very first page a visitor sees can
   never be validated. It presents as a 403 "Token verification failed", which
   points at the token rather than at the session underneath it.
2. Only the button that was clicked gets submitted. The posting form offers
   both preview and post; sending the pair means preview wins, the post is
   never made, and the response is a perfectly ordinary 200 with no topic behind
   it. formFields() therefore omits buttons and callers name the one they press.
3. Flood control will hit you. Security::spamProtection() allows a moderator
   one login or post every two seconds per IP, and tests are far faster than
   people. submitForm() waits it out once, which is the difference between a
   suite people trust and one that fails now and then for no reproducible reason.
4. curl only writes cookies that carry an expiry to its jar file. A handle
   opened per request loses the session cookie every time, so every request
   arrives as a new visitor — pages still render, but every POST is rejected.

Transactions

IntegrationTestCase gains usesTransaction(), and the HTTP tests return false
from it. They have to: the request runs in the web server's process on its own
connection, so nothing here is visible to it and nothing it does can be rolled
back — and on MySQL's default REPEATABLE READ an open transaction here would keep
reading the snapshot it took before the request, quietly making
assertNoErrorsLogged() incapable of ever failing. PostingTest removes what it
creates through SMF's own Topic::remove() instead.

One installer fix

install-forum.sh now removes install.php when it finishes. The installer says
to do this and cannot do it itself — ?delete is a GET and command line arguments
only reach $_POST — and leaving it puts a "MAJOR SECURITY RISK: you have not
removed install.php" banner across the forum. The new tests found it.

Credentials

The signing-in tests need to know the administrator. They default to what
install-forum.sh creates and can be pointed elsewhere with SMF_ADMIN_USER and
SMF_ADMIN_PASS. A password the suite does not know makes them skip with a
message saying so, rather than fail — that is a misconfigured forum, not a
regression. Verified both ways.

Verified

• 151 tests, 336 assertions, green on both engines, from the tree in this
  branch, with each forum's own administrator password.
• The flakiness is genuinely fixed: repeated full runs on PostgreSQL, and repeated
  PostingTest runs, all clean.
• check-signed-off.php, check-smf-index.php and check-smf-license.php pass;
  php-cs-fixer is clean under PHP 8.5; shellcheck clean on every .docker script.

Merge order

Merge #9345 before this one, and the PRs it names before that. This branch contains
the whole chain, so the diff shown here is mostly theirs; once #9345 lands and this is
rebased on release-3.0, what is left is tests/Integration/Http/.

Issues References (Fixes|Related|Closes)

1. Depends on [3.0][Testing] Add an integration test suite that runs against a real forum #9345 — extends IntegrationTestCase.
2. Depends on [3.0][Testing] Install the forum from the command line #9344 — install-forum.sh provides the forum, and is fixed here.
3. Related to [3.0][Testing] Add a Docker development environment for MySQL and PostgreSQL #9317.