grouped shares: hosting multiple shares in one server instance

For brevity I'll be calling this feature "grouped shares" from now on. What this does is allow one to create multiple SmbShare resources that will all be hosted by the same server group instance. For your standard deployment based instances this means a single smbd will host multiple shares; multiple shares will be accessible at a single "hostname" (smb://foo.ns.cluster.test/abc & smb://foo.ns.cluster.test/xyz).

The goal of this feature is largely one of resource efficiency. The ability to have SmbShares fully isolated from each other is a powerful default, allowing for things like mixing and matching AD domains or user-level security on a single logical unit (k8s cluster). However, having a large number of SmbShare resources can leave to a fair bit of overhead as each SmbShare will end up creating a pod running multiple daemons. As long as the shares are compatible - they share key settings like securityConfig and pvc, etc - we will permit grouping those SmbShares under one "instance".

This feature is enabled by adding the scaling parameters "Group" and "GroupMode". GroupMode must be set to "explicit" and a name provided at Group. The group name must be a valid k8s resource name. Example:

apiVersion: samba-operator.samba.org/v1alpha1
kind: SmbShare
metadata:
  name: share1
spec:
  shareName: "Share One"
  readOnly: false
  browseable: true
  securityConfig: sharesec1
  scaling:
    groupMode: explicit
    group: grouped1
    # ^^^ this is the new stuff
  storage:
    pvc:
      name: mypvc
      path: one

This finally implements one of the major planned features from the phase 1 design that had yet to be implemented.

One small downside of requiring grouped shares to be configured explicitly is that the creator of the SmbShares must plan ahead if the shares should be grouped or not. I think this is a small downside as I envion this feature mainly being used by tools that automatically provision shares. Imagine a CSI-alike that creates shares en-masse. That's largely the use case I'm thinking of for this. Of course, nothing stops a human admin from making use of it.

IMPORTANT: I am not planning on implementing and testing grouped shares for clustered instances in this PR. I was originally going to - but in order to get this PR reviewed earlier rather than later I have decided to work on combining the two scaling features later. I think that since clustered instances are experimental, this is an acceptable approach.

Also out of scope is the ability to change from ungrouped to grouped. Setting group mode to "never" (or leaving it unset) currently really does mean never. Similarly, it's not supported to change "explicit" to "never". Perhaps in the future we'll make it possible to migrate from one mode to another.

samba-in-kubernetes / samba-operator

grouped shares: hosting multiple shares in one server instance #240