[EKS] [request]: Please add support for `updateStrategy` to EKS addons efs-csi-node and ebs-csi-node

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Please add a possibility to specify `updateStrategy` for daemonsets in EKS managed addons (ie: aws-efs-csi-node or aws-ebs-csi-node).

**Which service(s) is this request for?**
EKS, EKS-Addons

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
As of now, `efs-csi-node` daemonset created by AWS EKS addon uses default `updateStrategy` (see below). On EKS clusters where nodes are coming on/off very frequent, the value of `maxUnavaible` set to `1` makes it very hard to rollout daemonset (~100nodes cluster takes more than 40minutes to roll daemonset).

```
$ kg ds efs-csi-node -o yaml | yq .spec.updateStrategy
{
"rollingUpdate": {
"maxSurge": 0,
"maxUnavailable": 1
},
"type": "RollingUpdate"
}
```

For comparison, `ebs-csi-node` has different configuration and using `maxUnavailable` on `10%` and rollout on the same cluster takes 1-2minutes only. Config example below as well.

```
$ kg ds ebs-csi-node -o yaml | yq .spec.updateStrategy
{
"rollingUpdate": {
"maxSurge": 0,
"maxUnavailable": "10%"
},
"type": "RollingUpdate"
}
```
I'd like to see the possibility to configure this `updateStrategy` on our own, so we can fine-tune it for our clusters. I see the value is supported in [upstream helm chart](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/charts/aws-efs-csi-driver/values.yaml#L183), so this change should hopefully be possible.

**Are you currently working around this issue?**
We don't have any workaround for this.

**Additional context**
n/a

**Attachments**
n/a

The request names the efs-csi-node and ebs-csi-node EKS add-ons and points to the upstream aws-efs-csi-driver charts/aws-efs-csi-driver/values.yaml file; start by comparing the existing updateStrategy settings there. Done means users can configure updateStrategy for these add-ons and the resulting DaemonSets honor that configuration.

Written by the indexing model from the issue text.