Geo: Smarter handling of deleted projects when hashed storage not in use

On GitLab.com, there is a pattern we occasionally see:

1. User creates project foo/bar
2. User deletes project foo/bar
3. User re-creates project foo/bar

If we process the delete event after step 3, we could remove a project from disk even though we didn't intend to do that. Hashed storage would solve that, but if it's not activated, we could perhaps do one of the following:

1. After removing the path, check if the project exists in another project ID. If it does, mark that project as needing a resync.
2. Alternatively, look for projects with the same path, and if one exists, don't delete the disk directory. The issue here is that the repo may contain stale data, so we may want to just resync.