fix(cdk): Resolve cross stack and default parameters for hotswaps

[Amplifiyer]

This PR solves two problems when doing hotswap deployments with nested stacks.

1. Adding capabilities to evaluate CFN parameters of AWS::CloudFormation::Stack type (i.e. a nested stack). In this PR, we are only resolving Outputs section of AWS::CloudFormation::Stack and it can be expanded to other fields in the future. See https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-cloudformation.html#w2ab1c17c23c19b5 for CFN documentation around using Outputs ref parameters
2. If a template has parameters with default values and they are not provided (a value) by the parent stack when invoking, then resolve these parameters using the default values in the template.

Partially helps #23533 and #25418

---

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.

[comcalvi]

I need to understand the addition of the sdk to an EvaluateCloudFormationTemplate before I can give this a better review.

[comcalvi]

why do we need this here?

[Amplifiyer]

In current CDK, evaluate-cloudformation-template can only evaluate CFN (Intrinsic) Fn references for resources in the same stack (Let's call it A) and hence it is passed a list of A's resources to assist in evaluation.

However the problem comes when a resource in A stack references resources in a different stack (Let's call it B). In that case evaluate-cloudformation-template of A has no knowledge of it.

This PR refactors evaluate-cloudformation-template in a way that it can recursively instantiate another evaluate-cloudformation-template for the referenced stack. And to do that, A's evaluate-cloudformation-template needs to pass in the list of B's resources while creating another instance and hence the sdk needs to be passed in for the A's evaluate-cloudformation-template so that it can call B's listResources

Now, instead of having the caller to get the list of stack's resources and pass it to evaluate-cloudformation-template, it's better for evaluate-cloudformation-template to manage it on it's own, since these resources are specifically being used by the evaluate-cloudformation-template and instead just pass the sdk rather than both sdk and the stackResources

[comcalvi]

this has been moved elsewhere, could you explain why? I don't see why this is necessary.

[Amplifiyer]

Answered here #27195 (comment)

[comcalvi]

Great work! This will merge soon, just need the integ tests to pass

[TheRealAmazonKendra]

Apologies, I stopped the integ test progress on this because I thought it was a change I pushed. I've restarted it now.

[aws-cdk-automation]

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

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

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).