[EKS] [request]: Tighten Security Group rules for NLB health checks

**Tell us about your request**
Currently if an AWS NLB is provisioned via kubernetes manifest/annotations the Security Group rules on the worker nodes are automatically modified to enable HealthChecks, ClientTraffic, MTU Discovery according to [k8s docs](https://kubernetes.io/docs/concepts/services-networking/service/#aws-nlb-support
).

At the moment the HealthChecks rule is too permissive, it allows the complete VPC CIDR block to reach the NodePorts on the worker nodes. It should be feasible to limit these rules to only the subnets the NLB has Elastic Network Interfaces associated with.
This request somewhat ties into a [similar request](https://github.com/aws/containers-roadmap/issues/439) for being able to define what subnets to use during NLB creation via kubernetes:

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

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

For multi-tenant architectures where subnets are used for network isolation instead of separate VPCs, the current setup will not meet a strict security posture.
Provisioning NLB outside EKS and later associating the worker nodes as target groups is a workaround but obviously adds a lot of complexity and ops. Especially if we are talking about an often changing clusters with many newly created/deleted NLBs.

As an example, let's say customer A has dedicated worker nodes that go into subnet A, same for customer B...etc. With the current setup the EKS managed SG rule would open up the NodePort to the whole VPC CIDR (all customers).

This feature + using "loadBalancerSourceRanges" annotation could enable tightly locked-down private clusters.

**Are you currently working around this issue?**
Currently NLB via EKS is not used-in production and this is a blocker to go live with customer traffic.

**Additional context**
Anything else we should know?

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start with the linked Kubernetes AWS NLB support documentation and related issue 439, focusing on how NLB subnets and worker-node security-group rules are selected. Define how health-check access should be limited to the subnets containing the NLB’s Elastic Network Interfaces while preserving client traffic and MTU discovery behavior. Done means the requested subnet-scoped health-check rules and their interaction with loadBalancerSourceRanges are specified and validated.

Written by the indexing model from the issue text.