feat(core): cfn constructs (L1s) can now accept constructs as parameters for known resource relationships

[leonmk-aws]

Issue # (if applicable)

Closes #.

Reason for this change

Allow passing L2s and L1s to L1s

Description of changes

Added a new relationship decider to parse the relationship information from the database and allow the other deciders to modify the properties / constructors accordingly. The relationship deciders assumes that:

• All modules will be built
• The properties in the relationship will exist (and have the same naming)

This generates code that looks like this for non nested properties:

In the properties:
readonly role: IamIRoleRef | string;

This is then used in the constructor:
this.role = (props.role as IamIRoleRef)?.roleRef?.roleArn ?? props.role;
If there were multiple possible IxxRef:
(props.targetArn as SqsIQueueRef)?.queueRef?.queueArn ?? (props.targetArn as SnsITopicRef)?.topicRef?.topicArn ?? props.targetArn

For nested properties

The props behave the same way, "flatten" functions are generated to recursively perform the same role that was done in the constructor for non nested properties:

function flattenCfnIdentityPoolRoleAttachmentRoleMappingProperty(props: CfnIdentityPoolRoleAttachment.RoleMappingProperty): CfnIdentityPoolRoleAttachment.RoleMappingProperty {
  return {
    "ambiguousRoleResolution": props.ambiguousRoleResolution,
    "identityProvider": props.identityProvider,
    "rulesConfiguration": (cdk.isResolvableObject(props.rulesConfiguration) ? props.rulesConfiguration : (props.rulesConfiguration ? flattenCfnIdentityPoolRoleAttachmentRulesConfigurationTypeProperty(props.rulesConfiguration) : undefined)),
    "type": props.type
  };
}

For arrays

 // @ts-ignore TS6133
function flattenCfnCodeSigningConfigAllowedPublishersProperty(props: CfnCodeSigningConfig.AllowedPublishersProperty | cdk.IResolvable): CfnCodeSigningConfig.AllowedPublishersProperty | cdk.IResolvable {
  if (cdk.isResolvableObject(props)) return props;
  return {
    "signingProfileVersionArns": props.signingProfileVersionArns?.map((item: any) => (item as SignerISigningProfileRef)?.signingProfileRef?.signingProfileArn ?? item)
  };
}

For arrays of nested props:

    this.fileSystemConfigs = (cdk.isResolvableObject(props.fileSystemConfigs) ? props.fileSystemConfigs : (props.fileSystemConfigs ? props.fileSystemConfigs.map(flattenCfnFunctionFileSystemConfigProperty) : undefined));

Database assumptions

Properties (the properties in sense of props of a resource but also prop of a type) have a a relationshipRefs array containing the relationship information:
relationshipRefs: [{ typeName: "AWS::IAM::Role", propertyPath: "Arn" }, ...]

Description of how you validated changes

Build works locally, will not pass here because it needs the changes in the database.
Checked the diffs between the previously generated code and the new one.
Added snapshot tests

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]

(This review is outdated)

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

[rix0rrr]

Add a unit tests somewhere that looks like this:

test('it works', () => {
  const stack = new Stack();

  const cfnRole = new CfnRole(stack, ...);
  const cfnFunction = new CfnFunction(stack, ..., {
    role: cfnRole,    // <-- I want to see this compile
  });

  Template.fromStack(stack).hasResourceProperties('AWS::Lambda::Function', { 
    Role: { Ref: ... }    // <-- and this produce the right template
  });
});

Can be any two resources that show up in the relationship data, pick your fave.