fix(ec2): 'encoded list token' error using Vpc imported from deploy-time lists

[rix0rrr]

Even though using Vpc.fromVpcAttributes() using deploy-time lists like
from Fn.importValue()s and CfnParameters was never really supposed
to work, it accidentally did.

The reason for that is:

// Encoded list token
const subnetIds = Token.asList(Fn.importValue('someValue'))
// [ '#{Token[1234]}' ]

// Gets parsed to a singleton `Subnet` list:
const subnets = subnetIds.map(s => Subnet.fromSubnetAttributes({ subnetId: s }));
// [ Subnet({ subnetId: '#{Token[1234]}' }) ]

// This 'subnetId' is illegal by itself, and if yould try to use it for,
// say, an ec2.Instance it would fail. However, if you treat this single
// subnet as a GROUP of subnets:
new CfnAutoScalingGroup({ subnetIds: subnets.map(s => s.subnetId) })
// [ '#{Token[1234]}' ]

// And this resolves back to:
resolve(cfnSubnetIds)
// SubnetIds: { Fn::ImportValue: 'someValue' }

---

We introduced an additional check in #11899 to make sure that the
list-element token that represents an encoded list ('#{Token[1234]}')
never occurs in a non-list context, because it's illegal there.

However, because:

• Subnet.fromSubnetAttributes() logs the subnetId as a warning
  to its own metadata (which will log a string like "there's something wrong with '#{Token[1234]}' ...").
• All metadata is resolved just the same as the template expressions
  are.

The resolve() function encounters that orphaned list token in the
metadata and throws.

---

The proper solution would be to handle unparseable list tokens
specially to never get into this situation, but doing that requires
introducing classes and new concepts that will be a large effort and
not be backwards compatible. Tracking in #4118.

Another possible solution is to stop resolving metadata. I don't
know if we usefully use this feature; I think we don't. However,
we have tests enforcing that it is being done, and I'm scared
to break something there.

The quick solution around this for now is to have
Subnet.fromSubnetAttributes() recognize when it's about to log
a problematic identifier to metadata, and don't do it.

Fixes #11945.

---

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

[gitpod-io]

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
• Commit ID: e1b27b4
• 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 master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).