fix two targetGroup related bug

[M00nF1sh]

Changes done

1. remove TargetGroup's port from TargetGroup replacement criteria. so that TargetGroups can be reused if only port differs.
   • this allow us to migrate from AWSALBIngressController/AWSLoadBalancerController(v2.0.0) with 0 downtime.
2. change the port for instance TargetGroup to be nodePort for better UX. (the port don't matter)
3. fix an edge that when same service referenced by both name and port, only a single TargetGroup are created. Now two different targetGroup will be created.
   Details:
   1. in both AWSALBIngressController and AWSLoadBalancerController(v2.0.0), we used the backendPort specified as resourceID(so it can be either port name or port number). Ideally different resourceID should result in different TargetGroup.
   2. in v2.0.0, even the model contains two targetGroup, only a single targetGroup will be created since the TG name is same, and due to ELBV2's API's idempotency. This works fine, however, it relies on ELBv2 API's implementation details and hacky.
   3. an alternative design is to always use the numeric port as resourceID. and to be backwards-compatible for backend port referenced by name, we can add a logic in targetGroup's cleanup logic to ignore TargetGroups's arn been used. we decided not to take this approach as it's hacky. (also, in the future, we might have extra logic to compress TargetGroup usage across Ingresses, so no need to compress for this edge case this time).

Test done

Pre steps:

1. Install AWSALBIngressController with 0 replica
2. Install AWSLoadBalancerController with 1 replica

compatibility test with AWSALBIngressController:

1. scale up AWSALBIngressController to 1 replica
2. launch Ingress with 4 path: echo: http, echo: 80, echo-ip: http, echo-ip:80. (echo is instance TargetType, echo-ip is ip TargetType, both http and 80 refers to same servicePort).
3. verify that traffic works, and 4 target group created.
4. scale down AWSALBIngressController to 0 replica
5. scale up AWSLoadBalancerController to 1 replica
6. verify the controller added elbv2.k8s.aws/cluster":"m00nf1sh-dev tags to resources, and kept old resources like LoadBalancer/TargetGroups.

compatibility test with AWSLoadBalancerController:

1. change to AWSLoadBalancerController v2.0.0 and scale up AWSLoadBalancerController to 1 replica
2. launch Ingress with 4 path: echo: http, echo: 80, echo-ip: http, echo-ip:80. (echo is instance TargetType, echo-ip is ip TargetType, both http and 80 refers to same servicePort).
3. verify that traffic works, and only two target group created.
4. change to AWSLoadBalancerController to image built with this change and scale up AWSLoadBalancerController to 1 replica
5. verify that the controller added two new targetGroup and configure rules properly.

[fawadkhaliq]

Let's pls add a comment why port=1 has no impact on the datapath as we override with a target

/lgtm otherwise

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: fawadkhaliq, kishorj, M00nF1sh
To complete the pull request process, please assign after the PR has been reviewed.
You can assign the PR to them by writing /assign in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fawadkhaliq]

/lgtm