SAM python debug: tries to resolve non-existent files

**Describe the bug**

I have a AWS Lambda function that I am attempting to step-through debug with VSCode. I am running into an issue where the behaviour of the debugger and VSCode does not make sense, claiming it cannot resolve non-existent files from paths that it should not be looking for these packages at.

The lambda function has been tested locally using the `aws-sam-cli`'s `sam build` and `sam local invoke` functionality. The lambda correctly takes a JSON event with `-e`, and returns the expected response. This has been tested with the following setup for its SAM template:

```yaml
Resources:
MyLambdaFunction:
Type: AWS::Serverless::Function
Metadata:
DockerTag: python3.8-v1
DockerContext: .
Dockerfile: Dockerfile
Properties:
PackageType: Image

```

The `launch.json`, referenced from https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/serverless-apps-run-debug-config-ref.html, is configured as follows:

```json
{
"configurations": [
{
"type": "aws-sam",
"request": "direct-invoke",
"name": "MyLambdaFunction",
"invokeTarget": {
"target": "template",
"templatePath": "${workspaceFolder}/path/to/template.yaml",
"logicalId": "MyLambdaFunction"
},
"lambda": {
"runtime": "python3.8",
"payload": {
"path": "${workspaceFolder}/path/to/input.json"
},
"environmentVariables": {}
}
}
]
}
```

When attempting to debug via `Run > Start Debugging` in VSCode, the docker build completes successfully, and the debugger attaches as per the AWS Toolkit logs. The Dockerfile in question is as follows:

```Dockerfile
FROM amazon/aws-lambda-python:3.8

COPY index.py requirements.txt ./
ADD mymodules ./mymodules
RUN python3.8 -m pip install -r requirements.txt -t .

CMD ["index.lambda_handler"]
```
After setting a breakpoint on the first line of `index.py`, which is `import time`, the debugger stops as expected and all is fine. When I begin to step through the lambda code, there is another import from one of my modules where I am importing `from elasticsearch import Elasticsearch`. This is where the first issue appears. VSCode throws an error window in the bottom right with the following message:

```
Unable to open 'socks.py': Unable to read file
'/Users/me/path/to/app/dir/lambdacode/urllib3/contrib/socks.py'
(Error: Unable to resolve nonexistent file
'/Users/me/path/to/app/dir/lambdacode/urllib3/contrib/socks.py'
```
Where `lambdacode` is the root directory containing the lambda code, module directories, requirement.txt, etc.

I am unable to determine why the debugger is looking for these packages at this workspace path. It seems as if the debugger is not utilizing the docker container at all, since it is looking locally for the packages. For reference, `urllib3` is installed system wide on my machine, installed in my virtual environment, and installed in the docker container in question.

Why is the debugger attempting to look exactly here in my workspace folder for the package, and is not utilizing the docker container? Is this a behaviour that I can change somehow? Even after stepping over this import and ignoring the error, there continues to be identical errors for other libraries such as `dateutil` etc, which are also installed everywhere that makes sense.

**To Reproduce**

To reproduce the same error, which occurs from the elasticsearch import:

1. Install aws-toolkit & aws sam cli
2. `sam init`
3. Choose 1 - AWS Quick Start Templates
4. Choose 2 - Image (artifact is an image uploaded to an ECR image repository)
5. Choose 5 - amazon/python3.8-base
6. Name the app
7. Choose 1 - Hello World Lambda Image Example
8. Add `from elasticsearch import Elasticsearch` to app.py and add `elasaticsearch` to `requirements.txt`
8. In VSCode, Run > Start Debugging
9. Observe the error. (Without this change, the application debugs as expected)

**Expected behavior**

The debugger to be able to step through the lambda in the built docker environment.

**Desktop (please complete the following information):**

- OS: macOS Big Sur 11.5.2
- Visual Studio Code Version: Version: 1.61.0 (Universal)
- AWS Toolkit Version: 1.30.0

Start with the launch.json direct-invoke configuration, Dockerfile, and AWS Toolkit debug logs, then reproduce the Elasticsearch import case using the listed SAM CLI steps. Trace how the debugger resolves dependency source paths and verify that stepping through the Lambda uses the built Docker environment without reporting nonexistent workspace files.

Written by the indexing model from the issue text.