fix(database): stop logging per page load and leaking two listeners

[karlitschek]

Stacked on #1124, which is stacked on #1123 and #1119. Both problems were introduced by those PRs, so if you would rather not carry a follow-up commit I am happy to fold this into them instead and drop this PR — say the word.

Two regressions the database page brought with it.

A warning in the log on every page load

A rule whose formula cannot be evaluated was logged at warning level. That is not an exceptional condition: a variable that is not numeric on this particular server is ordinary — MariaDB reports concurrent_insert as AUTO where MySQL reports an integer — and it happens on every single run.

The effect compounded badly. Every visit to the database page wrote a warning to nextcloud.log, and those entries are counted by core's "Errors in the log" setup check — on the very Overview page #1124 adds the database warning to. One new feature was quietly degrading another.

Measured on a MariaDB instance:

	failed to evaluate formula lines
three check runs, before	+3
three check runs, after	0

Nothing is lost by dropping the level. The rule already reports itself as skipped with the reason attached, which is where an admin should read it:

id        : Concurrent_insert_off
status    : skipped
skipReason: Formula could not be evaluated: Identifier 'concurrent_insert' is not numeric

The log line was only ever diagnostic detail, so it is now debug. The apply-descriptor failure sitting next to it stays a warning on purpose: that one means a rule is written wrong, rather than that this server is different from the one the rule was written for.

Two leaked event listeners

visibilitychange in the live charts and hashchange on the settings page were both registered with anonymous handlers and never removed — anonymous meaning they could not be removed. Both are now named and taken off in onUnmounted, which is what useLiveData already did and what I should have copied the first time.

The practical impact is small on a page mounted once per load, but it is the exact bug I flagged as avoided elsewhere, so it should not stand.

Note for upstream

The underlying Concurrent_insert_off rule is still wrong for MariaDB — it should skip cleanly on a flavour that reports the variable as a string, rather than failing to evaluate. That belongs in DB Doctor, where the rule comes from; fixing it here would diverge the ported copy and make the next re-sync harder.

eslint, php-cs-fixer and psalm clean; the committed js/css reproduce from a fresh build.

[karlitschek]

@susnux @artonge @Altahrim @AndyScherzinger @jancborchardt

[karlitschek]

/backport to stable35

[backportbot]

The backport to stable35 failed. Please do this backport manually.

# Switch to the target branch and update it
git checkout stable35
git pull origin stable35

# Create the new backport branch
git checkout -b backport/1125/stable35

# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts, resolve them
git cherry-pick 69909cda

# Push the cherry pick commit to the remote repository and open a pull request
git push origin backport/1125/stable35

Error: Failed to check for changes with origin/stable35: No changes found in backport branch

---

Learn more about backports at https://docs.nextcloud.com/server/stable/go.php?to=developer-backports.