feat: support extraVolumes and extraVolumeMounts

[cr1cr1]

closes #127

Definition of Ready

• I am happy with the code
• Short description of the feature/issue is added in the pr description
• PR is linked to the corresponding user story
• Acceptance criteria are met
• All open todos and follow ups are defined in a new ticket and justified
• Deviations from the acceptance criteria and design are agreed with the PO and documented.
• No debug or dead code
• My code has no repetitions
• Documentation/examples are up-to-date
• All non-functional requirements are met
• If possible, the test configuration is adjusted so acceptance tests cover my changes

[eliobischof]

Thank you for this great feature @cr1cr1 🥳

If you'd like us to send you a small gift in return, please send us a mail to hi@zitadel.com. We will send you a form with questions about your shirt size and address.

[cr1cr1]

@eliobischof thank you very much for the offer, it is unexpected and very appreciated.
I do not need a t-shirt, I just hope you keep building this great tool.

[aminebt]

Thanks for this very useful feature. We're actually using it to answer two use-cases to fetch desired info from secrets :
1/ providing SystemAPI public key (configured through a "Path" instead of the explicit public key)
2/ providing CA certificate to enable LDAPS

In our use-cases, (2) is optional whereas (1) should always be there. So a very handy addition could be adding the tpl function in the template for both extraVolumes and extraVolumesMounts :
{{- tpl (toYaml .) $ | nindent 10 }}
instead of
{{- toYaml . | nindent 10 }}

I think this would empower us to add arbitrary templating logic to the values themselves, and is compatible with the current usage of extraVolumes and extraVolumesMounts. For example, in our use-cases above, we could customize templating such that (1) is always there whereas (2) depends on another value.

Happy to get other suggestions/alternatives to customize further the chart deployment.