InitContainer checks incompatible with Istio Service Mesh

Describe your Issue

I understand this is a niche problem - Looking at #42 I can see why these checks are in place.

Given that, I still believe it would be valuable to have the initContainer have a conditional value in order for the postgresql-isready checks to be disabled when required.

My workflow is to deploy nextcloud on a cluster with Istio service mesh. I prefer that all of my workloads use mTLS encryption for traffic - which does not work well with the sidecar container strategy unfortunately.

My planned execution is to use Flux to deploy postgresql as a release separately of nextcloud in the same namespace and then have the nextcloud release depend on the postgresql release such that postgresql will always be happy before nextcloud installs/restarts.

Logs and Errors

Given that the sidecar for istio doesn't exist during initContainer runtime - the postgresql-isready cannot connect to the postgresql pods due to strict mTLS encryption.

Describe your Environment

Kubernetes 1.26.x

Start by locating the Helm chart configuration for the Nextcloud initContainer and its postgresql-isready checks, then review how values control related deployment behavior. Done means providing a conditional way to disable these checks while preserving the current default behavior and validating the chart deployment configuration.