Issue # (if applicable)

Closes #32805
Closes #20601

Reason for this change

This change is to better support image bundling in atypical (e.g. CI, DinD) environments by allowing volumes to be mounted using the more portable "Volume Copy" method, or to mount an existing volume. This supports use cases such as caching dependencies in CI environments to reduce asset bundling times.

Description of changes

The primary change made was the addition of two new DockerVolume varients (VolumeCopyDockerVolume and ExistingDockerVolume), facilitated by the new DockerVolumeHelper private class. This replaces the old asset-staging private classes AssetBundlingBindMount and AssetBundlingVolumeCopy, reproducing all the behaviours in a more flexible manner.
The decision to move these utility functions to private/bundling.ts was to better encapsulate the docker related behaviours and abstract them away from the asset management.

This currently uses a discriminated union type to clearly show which properties are required for each volume type. This passes linting, but if it's an issue it can be implemented just as an extension to the DockerVolume interface. However, I'm unsure how to best provide a clear developer experience with this approach.

How It Works

The interfaces for DockerRunOptions.volumes and the related BundlingOptions.volumes have been changed to accept VolumeCopyDockerVolume and ExistingDockerVolume as well as the existing DockerVolume type. The BundlingDockerImage.run() function has been modified slightly to instantiate a DockerVolumeHelper, which accepts the docker run options and uses them to prepare the volumes passed in, creating the volume command strings that run then uses.

If any if the passed volumes are VOLUME_COPY volumes, a copyContainer is spun up with each VOLUME_COPY volume atttached anonymously. The input copy is then performed using the same approach from AssetBundlingVolumeCopy. As these volumes are mounted to the primary container via --volumes-from, them being anonymous doesnt matter and makes creation and deletion of the helper more atomic, reducing the possibility of orphaned volumes or containers. Error handling has been added in multiple places to further prevent this happening in the case of a build failure.

BundlingDockerImage.run() makes use of the volume commands from DockerVolumeHelper to complete its image run, then runs DockerVolumeHelper.cleanup() to copy any outputs from the volume copy volumes, and delete the container (using the -v option to remove attach anonymous volumes).

Describe any new or updated permissions being added

N/A - All changes are at bundling time only

Description of how you validated changes

Unit tests were added to cover the new expected volume behaviours, and existing tests updated to match any changes to argument order. Tests were made to cover the new helper class and new error handling cleanup behaviour. No integration tests were made or modified as this is a local/bundling change,

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