[FHIR] added workflow to lint and test charts

[chgl]

Closes #36

Please note that this includes 3 changes which were arguably outside the scope of just adding a new workflow:

1. I had to reduce the default replicaCount to 1 because the hosted GitHub runners only have 7GiB of RAM by default (https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners). Note that alternatively we could specify custom values.yaml files to be used by chart-testing if we want to keep the default at 2 replicas (see https://github.com/helm/chart-testing/blob/main/doc/ct_install.md). Or we could remove the resource requests entirely. Or reduce the replica count to 1 by default and remove the resource requests/limits - which is maybe a bit more common among the charts found in the wild.

2. I added the home and type fields to the Chart.yaml - mostly because the chart-schema.yaml I copy-pasted had them set as required. The former adds a Homepage to the list of links on artifacthub - which may be nice, the latter is just for completeness sake.

3. I made the helm test job a bit more fault-tolerant by adding retries and increased timeouts. This should help avoiding flaky test behavior - this is related to the server becoming "ready" before the schema job has completed, see Add PostgreSQL as a subchart to simplify out-of-the-box installation #28 (comment)

[chgl]

Because I had forgotten to update the README.md using helm-docs in my original commit, I just added a new job to run pre-commit (and therefore helm-docs) as part of the CI as well.

Installation was a bit more involved since the https://github.com/pre-commit/action action is unfortunately deprecated.

[lmsurpre]

I had to reduce the default replicaCount to 1 because the hosted GitHub runners only have 7GiB of RAM by default (https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners). Note that alternatively we could specify custom values.yaml files to be used by chart-testing if we want to keep the default at 2 replicas (see https://github.com/helm/chart-testing/blob/main/doc/ct_install.md). Or we could remove the resource requests entirely. Or reduce the replica count to 1 by default and remove the resource requests/limits - which is maybe a bit more common among the charts found in the wild.

My thoughts:

1. I prefer a replica count of 2 because our server is stateless (minus caching for performance) and I think its best practice to have more than one replica. That said, I'm not totally opposed to dropping it to 1 if it gets us a running CI.
2. I want to remove the resource requests from the deployment, but I think we have some work to do there to make that possible. For historical reasons, the FHIR server defaults to a min and max heap size of 4GB. It does run with much less though. We have tasks under github.com/ibm/fhir for better understanding on our memory usage and that could inform our defaults. Til then, it is totally possible to override the default min/max heap size of liberty by placing a jvm.options file under configDropins/overrides. I've opened Support min/max heap size overrides #38 for that.

[chgl]

My thoughts:

1. I prefer a replica count of 2 because our server is stateless (minus caching for performance) and I think its best practice to have more than one replica. That said, I'm not totally opposed to dropping it to 1 if it gets us a running CI.

I completely agree, for any production usage, there should be more than 1 replica. But I also think a default of 1 is reasonable. I've added #39 which is helpful in >1 replica scenarios.

2. I want to remove the resource requests from the deployment, but I think we have some work to do there to make that possible. For historical reasons, the FHIR server defaults to a min and max heap size of 4GB. It does run with much less though. We have tasks under github.com/ibm/fhir for better understanding on our memory usage and that could inform our defaults. Til then, it is totally possible to override the default min/max heap size of liberty by placing a jvm.options file under configDropins/overrides. I've opened Support mix/max heap size overrides #38 for that.

Ah I see, thank you! This may be off-topic, but does setting XX:MaxRAMPercentage (https://www.atamanroman.dev/articles/usecontainersupport-to-the-rescue/) work? So we'd only have to specify the percentage once and then have it use the container resource limits.