fix(cloudwatch-actions): cannot add LambdaActions to alarms with the same id but different addresses

[tmokmss]

Issue # (if applicable)

Closes #30754.

Reason for this change

As decribed in the linked issue, the permission ids must be unique per Lambda function, and we cannot use alarm's costruct id to generate a permission id because alarm ids are not necessarily unique. To make sure its uniquenss, we use node address instead. A node address is guaranteed to be unique in a construct tree, so safe to use in permission id.

Description of changes

Because Lambda's resource policy (permission) is stateless, re-creating it with different logical ID is not a breaking change, as per the doc:

Not all template changes are breaking changes! Consider a user that has created a Stack using the previous version of the library, has updated their version of the CDK library and is now deploying an update. A behavior change is breaking if:
The update cannot be applied at all
The update can be applied but causes service interruption or data loss.

That is why this PR just removes the feature flag and replaced the permission id code instead of adding another feature flag, which would add more complexity to the behavior and UX if we had 2 similar flags related with this feature.

When you deploy an existing stack after this patch, CFn deploys in the following order:

1. start deployment
2. create a permission with new logical ID
3. delete a permission with old logical ID
4. finish deployment

So the permission for an alarm is active at any phase of the deployment.

Description of how you validated changes

add unit test and run integ test to confrim it deploys without disruption.

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.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[GavinZZ]

Putting this PR to state Request Changes while I double check with the team that changes like this is allowed.

Since there's change in logical id, it will result in CloudFormation resource deletion & recreation.

The only potential concern would be that if the CloudWatch Alarm transitions state while the old permission is deleted but before the new one is created, the Lambda function won’t be invoked because it temporarily lacks permission.

[GavinZZ]

@tmokmss We cannot accept this PR given the current state of change. I brought this up to the team to discuss internally, but we believe that this will be a breaking change for some users. This is because AWS IAM permission change is usually eventually consistent https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot.html, which means that there's potential concern would be that if the CloudWatch Alarm transitions state while the old permission is deleted but before the new one is created, the Lambda function won’t be invoked because it temporarily lacks permission.

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.