fix(rds): fix unresolved endpoint socket address

[jogold]

Convert port to a string token before using it in socketAddress otherwise the number token is
converted to a string and cannot be resolved.

Fixes #2711

---

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.

[eladb]

This actually looks like something I'd like tokens to be able to do. @rix0rrr what do you think?

const num = Token.asNumber({ "Fn::GetAtt": [ "Boom", "Port" ] });
const text = `Hello, ${num}`;

Should resolve to:

{ "Fn::Join": [ "", [ "Hello, ", { "Fn::GetAtt": [ "Boom", "Port" ] } ] ] }

I think??

[jogold]

@eladb found a "nicer" fix in the mean time, see latest commit.

Agree that it would be nice if this would be handled by the token system.

As the fix here implies, wouldn't this need something like a .toString() for number tokens that would convert them to string tokens and not string representation of a number? But those are of type number?

[rix0rrr]

Elad, so you're saying we should also be scanning strings for stringified versions of number-encoded tokens? I mean, technically possible, but pretty tricky I'm expecting.

(Also, purity nitpick: to properly mirror the language type system into the document type system, we would then need to produce a stringified version of the number in the CloudFormation document language as well, which we can't. Good thing is that CFN probably doesn't care about the distinction all that much...)