Updated: An emptied help content cache is filled in the background and by exp:velocity deploy, never inside a visitor's request

Reading every help object again takes about 35 seconds, more than Velocity's 30 second limit, and a cleared cache (ezcache --clear-all, --clear-id=exphelpcontent, --clear-tag=exphelp) made the next help request do it.

- A web request that finds the cache missing, or not updatable by reading only what changed (a changed help class or section, more than 300 changed objects), starts php bin/php/exphelpcontent.php cache -s <its siteaccess> detached with setsid, once (a marker file next to the cache keeps a second one from starting for 15 minutes), and answers at once without help content: the dashboard leaves out its help content part, the search finds no help topics, a topic or manual is not found, the context help keeps its last list. The next request after the command finished has everything again. A search that would compute the search words of every topic does the same. Where no background command can be started (no proc_open, setsid or command line PHP) the request reads the objects itself, as before.
- exp:velocity deploy fills the help content cache after the cache clears and before the warm-up requests, one PASS/FAIL step per siteaccess that shows the help: exphelp.ini [ContentSettings] CacheSiteAccessList[] and the siteaccesses that have used the cache (recorded next to it in siteaccesses.json). exp:help:content cache answers SKIP where help content is not installed or switched off, and the deploy step reports SKIP.
- New settings exphelp.ini [ContentSettings] CachePhpBinary (the command line PHP; empty: found next to the running PHP, also next to PHP-FPM) and CacheSiteAccessList[].
- The generated pages of the command exp:help:content (English and German) list the action cache, and the page of [ContentSettings] the new settings.
- Proven on a copy of alpha's database: after ezcache --clear-id=exphelpcontent the first dashboard request answered in about 2 seconds without the help content part and started the build, the background command wrote the cache in 19 to 41 seconds, and the dashboard after it was identical to the one before the clear, for an administrator and an editor.
- Tests: expHelpContentAccessTest covers the command line PHP, the marker, the recorded siteaccesses and the deploy step's place and SKIP.

Merge remote-tracking branch 'origin/main' into worktree-agent-ab0fc33b3397de055

# Conflicts:
#	share/filelist.md5

Updated: The help dashboard reads help maintained as content from a cache checked against the help subtree, and decides who sees it from the cached rows

The dashboard took 16 seconds on Apache and ran into Velocity's 30 second limit: every request loaded the 5,700 help objects with their data maps and then asked each object for canRead() and canEdit(), to show six topics, a count and the manuals. The search for help topics, the topic view, the manual list and the context help's released list paid the same.

- The repository keeps its rows in var/<site>/cache/exphelp/content, checked on every request against a stamp of the help subtree (sums over the locations, objects and states below the help root, the help classes and the sections). After a publish, translation, move, removal, state or section change only the objects whose signature changed are read again. index() gives the rows without the topics' texts, load() with them, accessData() what the permissions are decided with. Cache item exphelpcontent (site.ini [Cache_exphelpcontent], tag exphelp).
- Added expHelpContentAccess: content/read and content/edit decided from the cached rows as eZContentObject::checkAccess() compares the limitations; the object is asked only where it alone can tell (Group, an extension's limitation, the anonymous own-session owner, the member management guard).
- The dashboard picks the newest topics and the count with newestTopics(), without the texts and without loading an object. On a copy of alpha's database its help part takes 0.5 to 2 seconds instead of 16 to 35, with identical content for an administrator, an editor, a member, a help editor and a user with section, subtree, node, owner, language and depth limitations.
- The search words of every topic are kept in a second cache file and computed again only for changed topics (a search for help topics took 25 seconds, now about 1).
- Reading every help object again asks for the attributes one version and language at a time with the attribute table first (30 seconds with the kernel's single query on SQLite, about 1), and the states of all objects in one query.
- Added ./console exp:help:content cache -s <siteaccess> to fill the cache after a deploy.
- The context help's list of released help_ids is kept in a static property, so a persistent worker no longer keeps it for good.
- Tests: expHelpContentAccessTest (no database). Documented in the help content feature page and the 6.0.15 changelog.

Merge remote-tracking branch 'origin/main' into sqlite-guard

Updated: content/upload logs no errors for the upload parameters it was opened without

Opening content/upload directly (the Media library's upload in the legacy
admin) starts an upload without parameters. The upload view reads the optional
ones (result_uri, result_module, keys, ui_context, navigation_part_identifier
...) to decide what to do, and eZContentUpload::attribute() logged each missing
one as an error, and the upload templates fetched the content object of an
upload without one (object_id NULL), so every upload left nine lines in
error.log.

- eZContentUpload::attribute() answers null without an error for the
  parameters an upload can be started with; an unknown name is still an error.
- The upload templates of the admin, admin4 and standard designs fetch the
  object only when the upload has one.

Updated: eZPersistentObject on SQLite never replaces the row of another version

storeObject() inserts with "INSERT OR REPLACE" on SQLite, and REPLACE deletes
every row that collides with the new one on any unique key of the table. A
schema made by the Platform (Doctrine) gives ezcontentobject_attribute (and,
on some lines, ezworkflow, ezenumvalue, ezrss_export and others) the key (id)
alone, while the legacy kernel stores one row per (id, version). Copying an
attribute into a new version therefore replaced the row of the published
version: on Exponential Platform Nexus with SQLite every edit in the legacy
admin deleted the published content's attributes.

- eZSQLite3DB::uniqueKeyColumns() reads a table's primary key and unique
  indexes; insertOrReplaceIsSafe() is true only when each of them holds all of
  the keys the object is stored by, and warns once per table otherwise.
- storeObject() uses REPLACE only then; elsewhere it inserts plainly, so a
  collision fails with an error and no row is deleted.

A table keyed by a part of the legacy key still cannot hold a second version:
it needs the legacy key (the projects' schema completion rebuilds such tables,
keeping their rows). Rows replaced before this change cannot be restored.
A test stores two versions into both kinds of table in memory.

Updated: The SQLite driver answers MySQL's MOD() function

eZ Tags reads the main language bit of a tag's language mask with
MOD( language_mask, 2 ). SQLite builds without the math functions (3.34,
which PHP 8.0 to 8.5 use here, among them) do not know MOD, so the query
failed with "no such function: MOD" and took the surrounding transaction
with it: opening the edit form of content with a tags field in the legacy
admin on SQLite ended in a "database transaction failed" page.

eZSQLite3DB registers MOD next to its BIT_OR and BIT_AND aggregates, with
MySQL's answers: NULL for a NULL argument or a zero divisor, the sign of the
dividend, a fraction for decimal arguments. A test runs the function and the
eZ Tags query on a database in memory.