feat(fluent-bit): Add automountServiceAccountToken override at pod level

[gsmith-sas]

This change allows users to override the automountServiceAccountToken setting at the pod level. The Kubernetes API allows this property to be set at two levels:

• ServiceAccount level - when set at the ServiceAccount level, the setting impacts all pods associated with the ServiceAccount. The default value for this property is "true" meaning that the API token of the ServiceAccount is automatically mounted to any pod associated with the ServiceAccount.

• Pod level - when set at the Pod level, the setting only impacts that specific pod. When set at both levels, the Pod-level setting overrides the ServiceAccount level.

As described in PR #629, many sites require that this property be disabled for security reasons since the default value of "true" makes API tokens available by default. And, some security scans will flag this default behavior as potentially problematic. The change in PR #629 allows users to disable this setting and, when disabled, disables it at both the ServiceAccount and Pod levels.
However, there are situations where it is appropriate to disable this setting at the ServiceAccount level but enable it at the Pod level. For example, when configuring Fluent Bit to collect Kubernetes Events, access to the API tokens is required. The solution is to disable the setting at the ServiceAccount level (which PR#629 now permits) but enable it at the Pod level (which PR#629 does not permit). This PR is designed to allow users to enable this.

In this PR, I chose to name the new property automountServiceAccountToken even though that is very similr to the new property added in PR #629 (which added serviceAccount.automountServiceAccountToken). While this is potentially confusing, I think aligning the names of the Helm chart values with the properties they impact in the underlying Kubernetes resources is critical. This naming is consistent with other Helm charts I have reviewed (e.g. the Grafana Helm chart that support setting this property at both the ServiceAccount and Pod levels. I have also attempted to minimize confusion by adding comments immediately before both properties in the values.yaml file explaining the scope of each property.

[stevehipwell]

Thanks for the PR @gsmith-sas. This is my preferred pattern, although I wish I'd requested the value added in #629 be serviceAccount.automountToken which is my usual pattern.

[stevehipwell]

@gsmith-sas could you rebase this PR?

[gsmith-sas]

{heavy sigh} Looks like I messed up the rebase and lost the DCO on the last commit as well. 😦 Closing this PR and have opened a new clean(er) one (#633) Sorry for the churn.