feat: allow usage of existing service account

[aslafy-z]

No description provided.

[d3adb5]

Left a few comments. I like the idea of adding a semantic value like this, but I feel the way it currently is introduces more confusion than clarity. I expanded upon this in one of the threads I opened below.

[d3adb5]

I fear that this may just cause confusion when reading release values later down the line. I'd much rather have .Values.rbac.enabled be changed to .Values.rbac.create instead, but I realize that would be a breaking change. The way things are in this PR, I find it a bit confusing for a release using an existing service account:

• .Values.rbac.serviceAccount.name exists, but is completely empty, meaning default or disabled. The comments hint at the default value being {{ include "application.name" $ }}.
• .Values.rbac.serviceAccount.enabled exists and is set to false. What that means is unclear unless we peek into the templates or make an assumption based on widely available charts.
• .Values.rbac.existingServiceAccount exists is finally what we were expecting. Its mere presence introduces branching in the line of code this thread highlights.

If instead we had .Values.rbac.serviceAccount.create as a boolean defaulting to false, .Values.rbac.serviceAccount.name would always have the name of the mounted (when applicable) service account.

Do you believe this legibility tradeoff is enough to justify a breaking change? I find myself unable to make that judgment.

[d3adb5]

Edge case, may or may not be something to take into consideration: service accounts named null. Also, we're assuming the result of this partial template to be interpreted as YAML rather than a raw string, that may create confusion.

Suggested change

	{{- default "null" .Values.rbac.existingServiceAccountName }}
	{{- $saName := .Values.rbac.existingServiceAccountName }}
	{{- empty $saName | ternary (quote $saName) "null" }}

[d3adb5]

This partial template (or whatever replaces it) needs to be used in application/templates/rolebinding.yaml as well and anywhere else where template "application.name" $ (+ other branches) was used to come up with a service account name.

Would be good to add test cases for the templates that use it, though that might lead to duplicated tests.