(assets): EXTREMELY slow bundling with docker.

### General Issue

I have a lambda nodejs function that is taking over half an hour to bundle.

### The Question

I have seen the other github issues complaining about docker bundling taking 20 seconds up to around 4 minutes. I am experiencing bundling taking several times longer than that.

```typescript
const signDocumentsLambda = new lambda.NodejsFunction(
this,
generateName('lambda'),
{
entry: path.join(__dirname, '../src/index.ts'),
handler: 'handler',
functionName: generateName('lambda'),
bundling: {
nodeModules: ['pdfkit'],
forceDockerBundling: true,
commandHooks: {
beforeBundling: () => [],
beforeInstall: () => [],
afterBundling: copyAssetsAfterBundling,
},
},
}
)
...
const copyAssetsAfterBundling = (inputDir: string, outputDir: string) => {
return [
`cp -rf "${path.join(inputDir, 'src', 'bin')}" ${outputDir}`, // copy binary assets for pdf libraries
`cp -rf "${path.join(inputDir, 'src', 'render', 'fonts')}" ${outputDir}`, // copy fonts to /fonts
`cp -rf "${path.join(inputDir, 'src', 'render', 'images')}" ${outputDir}`, // copy images to /images
]
}
```

I need to copy some assets (fonts and images) after bundling, and I need to include `pdfkit` binaries to I can do operations on PDFs in my Lambda function. This works and functions just fine, but bundling takes FOREVER. I am writing this issue while waiting for `cdk deploy`.

Here is what my terminal looks like:
```sh
[+] Building 880.6s (3/12)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.13kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for public.ecr.aws/sam/build-nodejs14.x:latest 1.1s
=> [1/9] FROM public.ecr.aws/sam/build-nodejs14.x@sha256:e6ea34c50ba2429ebe4abf0794e611f95b4ddd5713ccebe636e94423649a9464 879.2s
=> => resolve public.ecr.aws/sam/build-nodejs14.x@sha256:e6ea34c50ba2429ebe4abf0794e611f95b4ddd5713ccebe636e94423649a9464 0.0s
=> => sha256:b69bee44f907c796c3afc971c0012cb3b8a79c8e3349980ecea5f527e4f28c93 81.58kB / 81.58kB 1.3s
=> => sha256:678592bfe0bcd99289d5de44b93b310014551726dbe149c11545364feeb2c6a8 36.35MB / 36.35MB 190.0s
=> => sha256:3967a671955bd41a974d02b2da91740fda7c47fe9bac4a78b485838ca12d96a3 9.25MB / 9.25MB 50.9s
=> => sha256:6eb4ada699d1c4429779ef6af626cd8302d6d864d7b1564ce7995d87f1162c2a 2.42kB / 2.42kB 0.0s
=> => sha256:249c3fbef36b621cf436ef1ce012c3d98a6d7fc63cc503ae3a83885880b84bd5 5.95kB / 5.95kB 0.0s
=> => sha256:e6ea34c50ba2429ebe4abf0794e611f95b4ddd5713ccebe636e94423649a9464 772B / 772B 0.0s
=> => extracting sha256:b69bee44f907c796c3afc971c0012cb3b8a79c8e3349980ecea5f527e4f28c93 0.1s
=> => sha256:4fd754d9c5c7377545dae9dabf9107cfadb7d8934d436b28811c437d24e5e668 270.53MB / 488.63MB 879.2s
=> => sha256:ee3a83f3774459dc74d298775da20b8cf92933fa735b1ce3e3e2be7df4032acb 147B / 147B 51.4s
=> => sha256:e94bd91809b32c46b6353154bb0c7588d75d42ce5ffd0d0b9dfe0031ec06bc78 43.68MB / 43.68MB 260.6s
=> => extracting sha256:678592bfe0bcd99289d5de44b93b310014551726dbe149c11545364feeb2c6a8 2.1s
=> => sha256:834e9e90d91770f6e65fd4050c35d6003dbbe47400da783bdf3aeb17e1b5b7c9 45.69MB / 45.69MB 424.2s
=> => extracting sha256:3967a671955bd41a974d02b2da91740fda7c47fe9bac4a78b485838ca12d96a3 1.1s
=> => sha256:427cb0c5a38f7c6cfb3c38f5e0274da1425c34990ea0dadfe186bf2aa8f6ae89 95.00kB / 95.00kB 262.9s
=> => sha256:a5a29591c452d213153569792d3656d254ed4ab900190df7c89d83ac4024d672 60.67kB / 60.67kB 264.1s
```

I have no idea why it is taking so long.

### CDK CLI Version

1.121

### Framework Version

1.144

### Node.js Version

14

### OS

macOs

### Language

Typescript

### Language Version

_No response_

### Other information

_No response_

Start with the lambda.NodejsFunction configuration using forceDockerBundling and the Docker output showing the public.ecr.aws/sam/build-nodejs14.x image pull; the entry point is ../src/index.ts and asset handling is in copyAssetsAfterBundling. Compare the image-build stage with the bundling hooks and verify that pdfkit, fonts, images, and binaries still bundle while the extreme delay is resolved.

Written by the indexing model from the issue text.