Support installing composer packages for Nextcloud apps

[theCalcaholic]

There seems to be some disagreement within Nextcloud, whether apps should or shouldn't bundle their dependencies. Currently, at least the notifications app doesn't bundle them and requires a composer install before working (see notifications#3206), breaking the app installation as implemented in nextcloud-e2e-test-server.

Either, nextcloud-e2e-test-server should add support for installing composer packages for apps or Nextcloud's own apps should always bundle those dependencies.

Also affects nextcloud/nextcloud-docker-dev (but is easier to workaround there).

[luflow]

Another affected consumer: the attendance app's Playwright suite broke the moment we moved our test server from stable33 to stable34, with the stacktrace from nextcloud/notifications#3206 — configureNextcloud(['notifications', ...]) clones the shipped app and app:enable then dies on the missing vendor/autoload.php. Both 0.4.0 and 0.5.0 are affected; the clone path is unchanged between them.

Two workaround shapes, in case it helps whoever implements this:

1. Drop the composer directory after cloning. No PHP or Composer needed on the host:

await runExec(['git', 'clone', '--depth=1', `--branch=${branch}`,
    'https://github.com/nextcloud/notifications.git', 'apps/notifications'], { container })
await runExec(['rm', '-rf', 'apps/notifications/composer'], { container })
await runOcc(['app:enable', '--force', 'notifications'], { container })

Without composer/autoload.php, OC_App::registerAutoloading() falls back to registering PSR-4 for lib/ itself, which is exactly what happened on stable33. In-app notifications work.

Caveat worth knowing: this does not make the app whole. The mozart-bundled classes in lib/Vendor/ are still missing, so anything touching web push logs Class "OCA\Notifications\Vendor\Minishlink\WebPush\VAPID" not found (from lib/WebPushClient.php). Fine for suites that only assert on in-app notifications, not fine if a suite exercises push.

2. Run composer install on the host and ship the result into the container — @theCalcaholic's approach above. This yields a complete app (the post-install-cmd runs mozart), at the cost of requiring PHP and Composer on the host. That's given on ubuntu-latest runners.

A built-in option would ideally cover both: composer install where a host toolchain is available, and the composer/-removal as a documented degraded fallback.