[EKS] [request]: Increase branch ENI Density

### 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**
With the recently launched feature of using ["Security group for Pods"](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html#supported-instance-types), it leverages Branch ENI and the number of the Pods that can be spawned is only around 1/3 of the original [Density](https://github.com/powerupcloud/aws-eks-rhel-workers/blob/master/files/eni-max-pods.txt).

If we take example of c5.large / m5.large it supports up-to 29 Pods per host, however with Security groups assigned to Pods, only 9 Pods can be launched.

**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?**

Currently we are using Calico Network policies to restrict egress communication to RDS. With this new feature of assigning "security group for pod", it would be more efficient to restrict egress communication to RDS.

We have special use-case where one user is mapped to one pod and we run lot of very small backend Pods and these backend pods would further communicate with RDS. Due to very high number of small pods (each pod would use around 75 to 100m CPU requests allocated), Pod density is very critical factor.

**Are you currently working around this issue?**
By not using "Security group for Pod" feature and continue using Calico network policies to restrict egress communication to RDS.

**Additional context**

- Currently one Pod is mapped to one Branch ENI, if somehow mapping of more number of pods (of same deployment) to a same Branch ENI can also solve our use-case to improve the Pod Density.
- Only one Trunk ENI can be created per Host, if we allow multiple such Trunk ENI's (per host) then it can also help in further improving Pod density. This may not completely solve our problem since Pod Density would not increase drastically.

Example: C5.large / m5.large can have upto 9 Pods, if we double the Trunk ENI then still we can only launch 18 Pods.

Each pod (75m CPU request) X 18 Pods = 1350m CPU. So we still cannot fully utilize the host

Start with the linked AWS Security groups for Pods documentation and the referenced files/eni-max-pods.txt to understand current Branch ENI and pod-density limits. Compare the proposed approaches—sharing Branch ENIs or allowing multiple Trunk ENIs—and define completion as increased pod density for EKS workloads using pod security groups without losing the stated networking behavior.

Written by the indexing model from the issue text.