Provide a way to set securityContext for the setup initContainer

[WolfspiritM]

Describe the bug
I've graylog running in a istio enabled cluster which results in istio catching all traffic. The istio proxy however is only started as a normal container and not available for initContainers. Therefor the kubectl can't be downloaded. Istio requires the initContainers to have "runAsUser: 1337" defined in the initContainer securityContext to bypass the proxy. (https://istio.io/latest/docs/setup/additional-setup/cni/#compatibility-with-application-init-containers)

Adding a way to specify securityContext for the setup initContainer would be nice

Version of Helm and Kubernetes:

Helm Version:

$ helm version
version.BuildInfo{Version:"v3.3.1", GitCommit:"249e5215cde0c3fa72e27eb7a30e8d55c9696144", GitTreeState:"clean", GoVersion:"go1.14.7"}

Kubernetes Version: 1.21

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T16:31:21Z", GoVersion:"go1.16.1", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.8+rke2r1", GitCommit:"4a3b558c52eb6995b3c5c1db5e54111bd0645a64", GitTreeState:"clean", BuildDate:"2021-12-15T21:37:43Z", GoVersion:"go1.16.10b7", Compiler:"gc", Platform:"linux/amd64"}

Which version of the chart:
1.9.2

What happened:
Graylog deployed without master service

What you expected to happen:
Graylog deployed with master service

How to reproduce it (as minimally and precisely as possible):
Deploy to an istio enabled cluster/namespace

Anything else we need to know:

[stieler-it]

I noticed that the (default) security context is applied to both init and main container. This seems to fail since the init container tries to chown the data directory to itself.
chown: /usr/share/graylog/data/: Operation not permitted
So if I am right this feature should help here as well.