fix: clean up missing project if it's gone, fixes #5322

[rfay]

The Issue

• 'unable to create project at project root' error message should say how to fix the problem #5322

People periodically delete a project's filesystem without doing a ddev delete first

How This PR Solves The Issue

When the filesystem is gone, remove the project from the project list

Manual Testing Instructions

mkdir junk && cd junk && ddev config --auto
cd .. && rm -r junk
ddev list

You should see the project mentioned while it's being removed from registry, but it won't error and won't show up on the next ddev list.

Automated Testing Overview

Added TestGetProjectsMissingApp

Related Issue Link(s)

Release/Deployment Notes

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR.

• Test on Gitpod.
• Test on GitHub Codespaces.

[rfay]

One thing we may still want to do here is to support ddev delete <project> when the project is not in the global list. That way people having trouble with an existing database could explicitly delete it in the easiest way.

[stasadev]

Looks good to me, I like the automatic removal of a project from the list.

One thing we may still want to do here is to support ddev delete <project> when the project is not in the global list. That way people having trouble with an existing database could explicitly delete it in the easiest way.

This is a good idea, but probably beyond the scope of this PR.
I'll think about it when I come back to the task of cleaning up the docker's resources:

• <none> image is being created when a new and different image of same name is created #5073

[rfay]

This is a good idea, but probably beyond the scope of this PR.
I'll think about it when I come back to the task of cleaning up the docker's resources: #5073

That one is about docker images, here we're talking about the docker volume where the database is stored. I agree it belongs in a separate PR.