Fix file watcher infinite loops and improve logging for local invoke

[roger-zhangg]

Problem

The AWS SAM CLI file watcher was experiencing infinite loops during local development, particularly with LoopBack applications that create temporary .sandbox directories. This caused:

• Extremely slow local invoke startup times (8+ minutes in some cases)
• High CPU usage from continuous file system events
• Poor developer experience during local development

Solution

1. Add --no-watch flag to local start-api and local start-lambda

This flag would disable the default behavior where a change in codebase will reset the docker container. User can use this flag to debug a changing local dir, and kill & restart the command to pick up new changes.

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

[vicheey]

DO NOT MERGE.

[roger-zhangg]

This failing test seems unrelated, but will take a look

[roger-zhangg]

also passed on my local

(.venv) ruojiazh@842f577b9ad2 aws-sam-cli % pytest tests/smoke/test_all_commands.py::TestAllCommands -n 4
======== 510 passed in 111.96s (0:01:51) ========

[reedham-aws]

What is the reason that we no longer allow customers to provide a list of files/dirs to be ignored? It seems like that was the original intention.

[roger-zhangg]

What is the reason that we no longer allow customers to provide a list of files/dirs to be ignored? It seems like that was the original intention.

The root cause was actually not that. Originally the assumed root cause was few node lib is constantly changing when function is invoking and therefore triggering our file watcher, but then it turns out it's just the file watcher is somehow lagging and it picks up the filechanges way later than it should be. So the lib changes are done in build, which should be a legit change that should be picked up.

For what here is fixing, is in some sam project setup, it might have multiple lambda function sharing a same code dir (like a same file with different function as entrypoint). When we are doing sam local start-api, even only one function changes in code dir, our watcher will think every function has changed. Therefore killing the running container and putting everything into LAZY mode again. So the ignore pattern can't really fix this issue.

Instead, providing the --no-watch flag gives user more control on the scenario above. They can kill and restart the command when a reload is actually required.