Server logs inaccessible to sidecar with no security context

When run with no security context configured for the pod, i.e. not best practice but allowed, the users for each container do not match (which is best practice): server runs as 1000 always, fluent bit runs as 8243 but ultimately should not matter.

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ 

This means that as https://issues.couchbase.com/browse/MB-46485 was rejected, the logging side car has no access to the logs in the shared volume. The server container does not allow anyone other than the user & group to read the logs.

The use of a fixed UID is explicitly recommended against by Openshift: https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids 

On Openshift, there is a custom security context approach which means unless configured differently by the administrator (which is not recommended either) the UIDs have to use a specific range. Without this we could default the security context for the pods but unfortunately that would then break Openshift.

Currently the recommendation would be to run with a security context anyway, and we can cover this use case with documentation. It does mean that people may deploy without a context, see the issue and raise a support request instead of reading the documentation though.

We therefore need to make this section more visible particularly for log forwarding: https://docs.couchbase.com/operator/current/resource/couchbasecluster.html#couchbaseclusters-spec-securitycontext 

The other options are:

1. Update the server container to allow all to read the logs.
2. Update the fluent bit container to use the same UID. This may not work with randomisation on a per-container basis, or if the server container changes - it does not help the current containers either.