Document zeebe values

[Zelldon]

Adds the zeebe values to the parent values file and removes them from the old values file, to reduce redundancy. Document all zeebe related variables to follow best practices https://helm.sh/docs/chart_best_practices/values/

This means:

• Variable names should begin with a lowercase letter, and words should be separated with camelcase.
• Every defined property in values.yaml should be documented. The documentation string should begin with the name of the property that it describes, and then give at least a one-sentence description

Furthermore introduced own pattern: # [VarName] [conjunction] [definition]

VarName:

• In the documentation the variable name is started with a big letter, similar to kubernetes resource documentation.
• If the variable is part of a subsection/object we use a json path expression (to make it more clear where the variable belongs to).
  The root (chart name) is omitted (e.g. zeebe). This is useful for using --set in helm.

Conjunction:

• [defines] for mandatory configuration
• [can be used] for optional configuration
• [if true] for toggles
• [configuration] for section/group of variables

Need to adjust the README related to the Zeebe values

[npepinpe]

Great stuff! The conventions are something we could add in a contributing section for the future contributors. That should hopefully avoid some review back and forth in the future.

• ❌ The README for ccsm-helm still lists zeebe.JavaOpts and not zeebe.javaOpts as variable. Same for the zeebe sub-chart README. Though if you want to do that as part of adjusting the README in a separate PR, go ahead 🙂
• ❓ You mention extracting the values to the parent chart; can you explain why? What's the plan, will all sub chart have their values in the parent/umbrella chart? Why is this a better alternative?

Anyway, no need for a second review from my side 👍

[Zelldon]

Thanks for your fast review @npepinpe !

Regarding:

You mention extracting the values to the parent chart; can you explain why? What's the plan, will all sub chart have their values in the parent/umbrella chart? Why is this a better alternative?

Multiple things, one is to avoid the duplication (having multiple values files with the same content), which some times lead to problems. Furthermore I would like to have on single place to maintain. Additionally artifacthub also shows only the values file of the parent chart https://artifacthub.io/packages/helm/camunda-cloud-helm/ccsm-helm?modal=values which makes for me sense to add the values here