fix(elasticloadbalancerV2): consistent logicalId for addTargetGroups (under feature flag)

[ahammond]

Convention is that ListenerRules should have a logicalId with a Rule suffix. Follow convention while providing a feature flag to support people who already have resources deployed and need to stick with the legacy naming convention.

Issue

Closes #29496
Related to PR #29513

Reason for this change

Going forward, the logicalId produced should be consistent.

Description of changes

Made logicalId consistent by default while providing a feature flag to enable backwards compat for apps which have pre-deployed infra.

Description of how you validated changes

UTs applied.
Exemption Request: ITs are not required per docs

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[ahammond]

Exemption Request: ITs are not required for this change, per docs.

[ahammond]

I'm not sure if this is considered a Breaking Change or not.

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to an integration test file and the resulting snapshot.

PRs must pass status checks before we can provide a meaningful review.

If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request and/or Clarification Request.

✅ A exemption request has been requested. Please wait for a maintainer's review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: b581bc2
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[TheRealAmazonKendra]

I think that we need to revert the previous change and combine these two using optional props, not feature flags. If you are defaulting to false, it's generally an indication that the change isn't quite right.

[TheRealAmazonKendra]

Alright, we reverted the other one so here are my thoughts on the path forward here. I totally get why you originally went the route that you did but we try to minimize the amount of feature flags we add and adding two here didn't feel right.

Upon looking through your code and this package, I noticed additional inconsistencies. In the ApplicationListener class we add Rule as a suffix in both addAction on line 294 and in addTargetGroups on line 322. On the other hand, in the ExternalApplicationListener class we do not add Rule as a suffix on addTargetGroups on line 629 but we do add it in addAction on line 675.

What I'm thinking is this: what if we add an optional prop to these functions that is something to the extent of overrideDefaultId, or maybe something to indicate that it's a migration from on of the other functions, and use that to control whether or not Rule is added as a suffix. That way it's not a breaking change, and if nothing is added for that prop then we go with the current default.

That prop name probably isn't very good, though, so I'm totally open to better names.

What do you think?