[EKS] [Addon CoreDNS]: Allow Best Practises Configuration

### 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 allow implementing EKS coredns best practises using the addons configuration. At the moment it is not possible without patching the deployment created by the CoreDNS addon.

**Which service(s) is this request for?**

EKS CoreDNS Addon

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

We have been using the CoreDNS addon in it's (mostly) default configuration. After switching to Karpenter we experienced DNS resolution failures when coredns instances get restarted, e.g. due to being scheduled on another Node. We were able to solve the issues by applying the EKS best practises:

- The `lameduck` duration should be set to 30 seconds.
- Change the readiness probe to *[provide] ample time for the node’s iptables rules to be updated before pod termination*

See the best practises guide:

- https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_lameduck_duration
- https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_readiness_probe

We understand that changing the default behaviour of the CoreDNS addon will affect a lot of customers and so it is unlikely. In order to be backwards compatible it would be nicer if we could just pass the needed values for the readiness probe (`failureThreshold`, `periodSeconds`) and the `lameduck` value for the `Corefile.

**Are you currently working around this issue?**

We are currently working around this issue by providing a complete `Corefile` to the CoreDNS addon and patching the CoreDNS deployment after the addon configuration:

```
resource "null_resource" "patch_coredns" {
provisioner "local-exec" {
command = <

Start by reviewing the EKS CoreDNS addon configuration and the upstream CoreDNS Helm PR linked in the issue, then compare them with the AWS best-practices links. Done means the addon configuration can set the Corefile lameduck value and readiness-probe failureThreshold and periodSeconds without patching the deployment, while preserving backward compatibility.

Written by the indexing model from the issue text.