Create a helm chart for fast CS IOCs

[gilesknap]

• this should be published as an OCI chart by CI of this repo
• allows python projects that use fastCS to be deployed into a cluster
• question - could this instead be a helm chart for python-copier template in general

[gilesknap]

See #84.

Outstanding things to consider:

• currently I have used the same approach for configuration as C++ IOCs, that is a config folder and a template that ingests the contents into a configMap.
  • pro: familiar and well trodden path - and same for all IOCs
  • pro: can add additional files as needed - this came in handy for configuring the simulator as a second container for example
  • pro: keeps the fastcs-example yaml separate and therefore means easy schema management
  • con: suffers from needing to reboot the IOC on every commit hash change, like C++ IOCs currently have
• for consideration: merge the fastCS configuration yaml into the values.yaml. Then the services folder would just be Chart.yaml and values.yaml only.
• There is lots of overlap between the charts ioc-instance (for c++) and fastcs-instance - perhaps we could have a single ioc-instance that worked for both IOC types.
• TODO: livenessProbe, readinessProbe, stop hook.

[gilesknap]

IMPORTANT:

I have relied on using semver (which allows calver) including and check early in the helm workflow that the form of the tag is one of:-

• X.Y.Z
• X.Y.Z-alpha.A
• X.Y.Z-beta.B
• X.Y.Z-rc.R

These formats are compatible with Pypi (which translates them into X.Y.ZbB for example), Helm and Container tags.
We need to adopt this convention generally. I note that blueAPI has already done so.

Our previous form of X.Y.ZbB is OK as long as you are not publishing helm charts, but I think there is no harm in having one style to our tagging.

So at present I do the check early in the helm workflow - because it is annoying to wait for a release and find out at the end that your tag format is incorrect.

It is also true that the approach I have used for workflows means that adding helm support means adding a single workflow file _helm.yml and hooking it up in ci.yml only.

[gilesknap]

UPDATE: blueAPI are using a different helm values schema generator:
https://github.com/losisin/helm-values-schema-json

I've discussed this with them and am convinced that it is the better choice.

Before merging this PR I will attempt to convert our schema generation over to the above.