Add an automated isolated test-worker lifecycle with full database matrix support

[vitormattos]

Part of LibreSign/libresign#8969.

Context

nextcloud-docker-development already supports multiple independent development environments on the same host.

Each clone has its own filesystem/volume structure, and Compose project naming provides an additional namespace for containers and networks.

LibreSign wants to reuse this isolation model for parallel Behat workers instead of creating a second test-environment implementation.

To serve the complete LibreSign Behat matrix, the environment must support the four database backends currently exercised by LibreSign:

• SQLite;
• MySQL;
• MariaDB;
• PostgreSQL.

SQLite support is tracked in #141.
MariaDB support is tracked in #142.

Goal

Provide a stable, reusable automation contract that allows a CI/test consumer to create, use and destroy multiple isolated Nextcloud test environments concurrently on one host across the supported PHP, Nextcloud and database matrix.

The implementation must remain generic to Nextcloud development/testing and must not embed LibreSign-specific business behavior.

Worker contract

A caller must be able to select a worker using environment/configuration values without editing Compose files or scripts.

Use the following database-selection contract:

DB_TYPE=sqlite|mysql|mariadb|pgsql

DB_TYPE selects the database backend.

For service-backed databases, DB_HOST remains the connection/service host and should default consistently with the selected backend.

Existing MySQL/PostgreSQL callers that only use the current DB_HOST behavior must either remain compatible or receive an explicit migration path documented in the same change. Do not silently reinterpret a hostname as a database type.

The worker lifecycle must also allow callers to select:

• PHP_VERSION;
• VERSION_NEXTCLOUD;
• DB_TYPE;
• backend-specific supported version/configuration values where applicable.

Required lifecycle

The environment must expose a reliable non-interactive way to perform the equivalent of:

1. create worker environment;
2. select PHP / Nextcloud / database configuration;
3. start only the services required by that database backend;
4. install/configure Nextcloud;
5. make an app checkout available;
6. execute commands/tests against the worker;
7. collect diagnostics;
8. destroy only that worker environment.

The exact script/command names are implementation details, but the caller-facing behavior above is required.

Database matrix

SQLite

Tracked by #141.

• no external database container is required;
• database state lives inside the worker's isolated Nextcloud filesystem;
• the PHP image includes the required SQLite extensions.

MySQL

Preserve the existing supported MySQL development path.

MariaDB

Tracked by #142.

• MariaDB is selected explicitly with DB_TYPE=mariadb;
• the caller can select the supported MariaDB version without editing Compose YAML;
• initial support covers MariaDB 10.6 and 10.11.

PostgreSQL

Preserve the existing supported PostgreSQL development path.

Isolation

Workers must have separate mutable state for:

• clone/workspace directory;
• Compose project/network;
• Nextcloud configuration;
• Nextcloud data;
• database data;
• mail state where applicable;
• temporary/runtime files;
• logs and test artifacts.

Stopping or cleaning one worker must not stop or delete another worker's resources.

Shared immutable Docker images/caches are allowed.

Concurrency verification

Add automated coverage proving that at least two workers can coexist.

The test must use conflicting logical state so it detects accidental sharing, for example worker A and worker B set the same Nextcloud-visible key/resource to different values and each continues to observe its own value.

Run this isolation proof against at least one service-backed database and SQLite.

Database-specific children must separately prove their backend state is isolated.

CI suitability

The lifecycle must:

• be non-interactive;
• return meaningful failure codes;
• permit deterministic worker/project names supplied by the caller;
• clean up worker-specific resources after success or failure;
• make relevant logs discoverable;
• avoid requiring fixed host ports for worker-to-worker isolation;
• preserve existing local development use.

Security boundary

The repository documentation already states that its proxy infrastructure can access the Docker daemon.

Treat the Docker daemon as a trust boundary.

The lifecycle is suitable for isolated/ephemeral CI runners or trusted local code. Do not present Compose project names as a security boundary between mutually untrusted workloads sharing the same Docker daemon.

Performance

Reuse immutable images and caches where safe.

Do not share mutable Nextcloud/database state to reduce setup time.

Performance optimization must not weaken worker isolation.

Done when

• DB_TYPE=sqlite|mysql|mariadb|pgsql is supported and documented.
• Add SQLite as a first-class database backend #141 provides the SQLite backend.
• Add MariaDB as a first-class database backend #142 provides the MariaDB backend.
• Existing MySQL and PostgreSQL behavior remains functional.
• PHP and Nextcloud versions can be selected programmatically per worker.
• Backend-specific versions/configuration can be selected where required.
• Two or more workers can run concurrently without mutable-state leakage.
• Destroying one worker does not affect another.
• The lifecycle is non-interactive and suitable for CI automation.
• Automated lifecycle/concurrency tests exist.
• The trust boundary around Docker daemon access is documented accurately.

[vitormattos]

The worker lifecycle requirements are now covered by the merged implementation:

• Add isolated worker lifecycle foundation #144 introduced the isolated non-interactive worker lifecycle and DB_TYPE contract;
• Add SQLite as a first-class worker backend #145 added SQLite, including two-worker isolation and no external database service;
• Add MariaDB 10.6 and 10.11 worker backends #146 added MariaDB 10.6/10.11, SQL-mode configuration, database-level diagnostics and two-worker isolation;
• existing MySQL/PostgreSQL paths remain supported;
• workers select PHP/Nextcloud/database configuration through environment values;
• mutable state and Compose project names are isolated per worker;
• teardown is worker-scoped;
• CI covers unit/Compose behavior, SQLite isolation and service-backed MariaDB isolation;
• Docker daemon trust-boundary documentation remains explicit.

This completes the lifecycle foundation required by this issue.