What

This PR includes a fix for the hard coded reference to EnvironmentFile reference in the ecs AssetEnvironmentFile construct.

Why

Currently only a single AssetEnvironmentFile can be used with a container definition (as outlined in #21313). This is because the underlying "Asset" construct has a hard coded construct Id that conflicts when multiple AssetEnvironmentFiles are bound to the same scope.

How does this fix things:

This PR changes the way the ID is sourced for the Asset construct to ensure it is unique (But a stable value).
The new approach:

• Counts the number of adjacent constructs in the given scope with ids starting with EnvironmentFile
• Uses that count to generate a new ID following the pattern EnvironmentPattern{N}

Ids will be generated for each scope as follows:

• EnvironmentFile
• EnvironmentFile1
• EnvironmentFile2
• {...}
• EnvironmentFile{N}
  (This follows a similar pattern to the IDS generated for RDS Database Instances)

Why might this be a good approach?

I think this is likley going to be the least disruptive way of resolving this issue as:

• It will not involve any BC breaks (the first call to AssetEnvironmentFile.bind will always return a construct with an ID of 'EnvironmentFile')
• The public API's do not need to be updated /changed in order to effect this change.
• It increments based on a given "scope" so container definitions have EnvironmentFile(s) that increment independently.
• The order the calls to "bind" are made in a consistent manner so the internally generated ID's should not change between Synths

Possible issues with approach

There are some issues with this approach however including:

• In cases where many environment files are used there is the possibility for cascade updates. I.e EnvironmentFile2 gets removed and EnvironmentFile3 -> EnvironmentFile2, EnvironmentFile4->EnvironmentFile3. I am not sure if this is likely to cause issues.

RFC

It would be great to get some input if this would be an appropriate fix verses directly passing ID's down to the lower level constructs. (Or hashing the paths to the assets as suggested in the original issue)

If this looks good I can add some new test cases for this 👀
Closes #21313.

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