feat: physical names in the entire Construct Library

[skinny85]

This PR changes the xyzName attribute of all Resources in the Construct Library to be of type PhysicalName,
and adds an AWS linter rule that checks ensures conformance.

The name of the property can be any ending substring of the base name of the class with the Name
suffix - for example, if my resource is AwesomeFoobar, the name can be foobarName or awesomeFoobarName (that's because we often have Specialized1AwesomeFoobar and Specialized2AwesomeFoobar in our library, that share a base prop interface).

There were a few interesting cases in the library which I didn't change, as I wasn't sure of the semantics of the resources, or they would require class name changes. Would appreciate some guidance there. These were:

• @aws-kms: AliasProps.name
• @aws-ssm: ParameterOptions.name EDIT: changed to PhysicalName according to @rix0rrr 's suggestion below
• @aws-applicationautoscaling: ScalableTargetProps.resourceId
• @aws-route53: CommonHostedZoneProps.zoneName
• @aws-route53: RecordSetOptions.recordName
• @aws-apigateway: StageProps.stageName
• @aws-servicediscovery: BaseNamespaceProps.name
• @aws-config: CustomRuleProps.ruleName
• @aws-config: ManagedRuleProps.ruleName
• @aws-config: AccessKeysRotatedProps.ruleName
• @aws-config: CloudFormationStackNotificationCheckProps.ruleName
• @aws-config: CloudFormationStackDriftDetectionCheckProps.ruleName
  EDIT: changed the linter to take the resource name instead of the class name, and now @aws-config has been changed as well
• @aws-rds: DatabaseClusterProps.clusterIdentifier
• @aws-rds: DatabaseInstanceSourceProps.databaseName

BREAKING CHANGE: all resourceName attributes have their type changed from string to cdk.PhysicalName.

---

Pull Request Checklist

• Testing
  • Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
  • CLI change?: coordinate update of integration tests with team
  • cdk-init template change?: coordinated update of integration tests with team
• Docs
  • jsdocs: All public APIs documented
  • README: README and/or documentation topic updated
  • Design: For significant features, design document added to design folder
• Title and Description
  • Change type: title prefixed with fix, feat and module name in parens, which will appear in changelog
  • Title: use lower-case and doesn't end with a period
  • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
  • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
• Sensitive Modules (requires 2 PR approvers)
  • IAM Policy Document (in @aws-cdk/aws-iam)
  • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
  • Grant APIs (only if not based on official documentation with a reference)

---

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

[skinny85]

Continued from #2878

[rix0rrr]

I think you're correct on the resources you skipped, except I'm also unsure about a copule. I think these are just "usual" physical names, still. Am I wrong?

• @aws-ssm: ParameterOptions.name
• All the AWS Config Rule Names

[rix0rrr]

Pre-emptive approval but please check those resources.

[skinny85]

The problem with the @aws-config Rules is that the linter rule checks for the name of the property. If the class is called AwesomeFoobar, the physical name property has to be either foobarName or awesomeFoobarName. The Config Rule classes violate that - the property is called ruleName (makes sense), but the classes are called CloudFormationStackNotificationCheck, CloudFormationStackDriftDetectionCheck, etc. - so would require changing the class names.

@rix0rrr opinion on this? (and anyone else, of course)

[skinny85]

Another iteration. I've changed SSM's Parameter to PhysicalName, according to @rix0rrr 's suggestion, and solved a lot of conflicts that happened after #2372 was merged.

Would appreciate another pass!

[rix0rrr]

The problem with the @aws-config Rules is that the linter rule checks for the name of the property.

That shouldn't be a reason to not make them PhysicalNames though. It might mean we have to suppress the linter rules for those classes, OR we fix the linter to not look at the class name as a prefix, but the resource name as a prefix.

[skinny85]

The problem with the @aws-config Rules is that the linter rule checks for the name of the property.

That shouldn't be a reason to not make them PhysicalNames though. It might mean we have to suppress the linter rules for those classes, OR we fix the linter to not look at the class name as a prefix, but the resource name as a prefix.

Changed the linter to take into account the resource name instead of the class name in the newest version.