feat: Add useImageCode flag to support custom image-based deployments

[rizlas]

Description of the change

Add nextcloud.persistence.useImageCode flag to skip the /var/www and /var/www/html volume mounts when the application code is baked directly into the container image.

Benefits

This enables custom image-based deployments where application code is shipped as part of the image rather than live-synced via rsync. It allows greater flexibility and supports efficient upgrades and horizontal scaling in Kubernetes environments, avoiding the default volume mounts that would otherwise shadow the image content.

As an enterprise user I found the official enterprise Helm chart unsatisfying as it only targets the AIO deployment model. Both the enterprise and community images share the same rsync-based approach for live code delivery, which makes efficient upgrades and horizontal scaling impractical in Kubernetes environments. Despite paying for an enterprise subscription, I received no direct support and found the enterprise offering to add little value over the community counterpart. In fact, this community Helm chart is superior in every regard, especially for users who need a non-AIO deployment and customisation options.

A similar proposal for supporting immutable code images was already submitted in #496, confirming this is a recurring need in the community.

Possible drawbacks

Users enabling this flag must ensure their custom image exposes all required paths correctly, as no volume mounts will be applied to /var/www and /var/www/html.

Additional information

I reworked the community Apache-based Docker image by removing the rsync layer and adding support for enterprise code. The custom image is available at https://github.com/ConsortiumGARR/nextcloud-docker. I am currently testing this approach and plan to open a separate PR for the Docker image as well, hoping the changes will be accepted upstream.

Checklist

• I have read the CONTRIBUTING.md doc.
• DCO has been signed off on the commit.
• Chart version bumped in Chart.yaml according to semver.
• (optional) Parameters are documented in the README.md

[rizlas]

Some field experience since opening this. I have been running this flag in production for months, on a busy instance with a large user base, using a custom image that bakes the Nextcloud code into the layer instead of rsyncing it onto a volume at startup. No issues at all in that time. Startup no longer waits on an rsync of tens of thousands of files, the running code matches the image tag, and rolling back is a tag change.

I am now moving that deployment from apache to nginx and fpm, which is why the work has moved to a new repository: https://github.com/ConsortiumGARR/nextcloud-community-docker (it supersedes the nextcloud-docker repo linked in the description).

One caveat. With nginx.enabled=true, the flag also skips the /var/www/html mount on the nginx sidecar. That is correct only if the sidecar image carries the code too, so with the stock nginx:alpine image every request would 404. I build a matching nginx image for that, and with it no further chart change is needed. Happy to explain this in the values.yaml comment if you think that is the right place (check nginx image in fork repo of docker image).

I have not bumped the version in Chart.yaml. With the PR open this long, any number I pick goes stale as soon as another PR bumps it first, and I have no visibility on when, or whether, this lands.