feat(database): add a database page with the DB Doctor checks

[karlitschek]

Stacked on #1119. The base branch is feat/settings-tabs, because this adds a third page to the navigation that PR introduces — so the diff here is only the database work. GitHub will retarget this to master automatically when #1119 merges.

Why

The Monitoring app tells an admin what their database is — type, version, size — but never whether it is configured well. Nextcloud's DB Doctor app already answers that, so this ports its check engine into a third page sitting between Status and Background jobs.

On a stock Ubuntu MariaDB it surfaces 57 checks — 12 failing, 19 passing, 26 skipped — grouped by category.

What came across

• the rule engine (Rule, RuleResult, RuleSet, the expression evaluator, the advisor) and the probe that snapshots the server
• the MySQL/MariaDB rule set, which DB Doctor ported from phpMyAdmin's advisor. Its SPDX-FileCopyrightText for phpMyAdmin and the GPL-2.0-or-later provenance note travel with the file
• the PostgreSQL and Nextcloud schema rule sets
• the settings dialog for pointing the checks at a separate connection, so they can run as a user with rights Nextcloud itself does not need. Stored under serverinfo's own app config, password in the credentials manager, host validated against serverinfo.allowed_override_hosts
• the live connections, throughput and latency boxes, in one row above the checks

What deliberately did not

The score, grade, mascot, history and trend charts. This is a page about what is wrong, not a dashboard to score.

Everything that writes. Failing checks offer the config snippet to paste into my.cnf or postgresql.conf, but nothing applies a value. A bundled monitoring app has no business holding write access to the database it is monitoring, so ApplyService, ApplyController and the audit trail stayed behind.

The "Run check now" button. The checks run once when the page is first opened, and the results survive switching tabs and coming back.

Two departures from how DB Doctor does it

One live endpoint, not two. Its dashboard polls /insights/metrics every 3 s and /check/ping at 1 Hz. Measuring on a live instance, a poll spends about 1.3 ms collecting data inside a request that takes ~450 ms — the request cycle costs two orders of magnitude more than the work. So /database/live returns the metrics and times its own round trip in a single call, and the boxes poll only while this page is on screen and the tab is visible.

Both live endpoints close the PHP session first. This one bit for real: holding the session for the length of a ~5 s check made the Status page's 2-second poll queue up behind it, far enough to hit AH00161: server reached MaxRequestWorkers and hang the page indefinitely. $this->session->close() before the work fixes it; neither endpoint writes to the session.

The charts reuse the chart.js setup the CPU and memory graphs already use rather than porting DB Doctor's own SVG sparkline and its 481-line latency chart — less new code, and visually consistent with the Status page.

Verification

Driven against a live NC 35 instance with Playwright and measured, not eyeballed:

• /database/check returns 57 rules across 11 categories in ~1.2 s; the page renders 12 failing cards grouped by category
• live boxes render at identical size on one row (334×129 measured) with real values — 1 / 151 connections, 14 queries/s, 0.6 ms latency
• polling gating: 0 /database/live requests while on Status, ~7 per 30 s once on Database (median 418 ms), stopped when the tab is hidden
• the settings dialog round-trips: Test connection dials without saving, Save persists

eslint, php-cs-fixer and psalm are all clean, and the committed js//css/ reproduce from a fresh build. The psalm baseline grew for the DI-constructed classes and for the private OC\DB\* classes the Nextcloud schema rules need; Doctrine DBAL is stubbed in tests/stub.phpstub, following the pattern already there.

Worth a maintainer's opinion

This duplicates DB Doctor's rule engine inside a bundled app, so the two copies will drift. I kept the ported files structurally identical and preserved the upstream rule ids so a future re-sync is mechanical, but if you would rather serverinfo deferred to DB Doctor when it is installed — or that this lived somewhere else entirely — I would rather hear it now than after the copies diverge.

One known wart came across with the port: on MariaDB, Concurrent_insert_off logs "Identifier 'concurrent_insert' is not numeric" because MariaDB reports that variable as AUTO. The advisor catches it and marks the rule skipped, so it is cosmetic, but it is a DB Doctor bug worth fixing at the source rather than diverging the copy here.

[karlitschek]

[karlitschek]

@susnux @artonge @Altahrim @AndyScherzinger @jancborchardt

[karlitschek]

/backport to stable35