Fix an issue where loading a mangled project graph could fail too abruptly

Summary:
Ref T13484. If you load a subproject S which has a mangled/invalid `parentPath`, the query currently tries to execute an empty edge query and fatals.

Instead, we want to deny-by-default in the policy layer but not fail the query. The subproject should become restricted but not fatal anything related to it.

See T13484 for a future refinement where we could identify "broken / data integrity issue" objects explicilty.

Test Plan:
  - Modified the `projectPath` of some subproject in the database to `QQQQ...`.
  - Loaded that project page.
  - Before patch: fatal after issuing bad edge query.
  - After patch: "functionally correct" policy layer failure, although an explicit "data integrity issue" failure would be better.

Maniphest Tasks: T13484

Differential Revision: https://secure.phabricator.com/D20963

src/applications/project/query/PhabricatorProjectQuery.php

@@ -271,6 +271,25 @@ final class PhabricatorProjectQuery
 
     $all_graph = $this->getAllReachableAncestors($projects);
 
+    // See T13484. If the graph is damaged (and contains a cycle or an edge
+    // pointing at a project which has been destroyed), some of the nodes we
+    // started with may be filtered out by reachability tests. If any of the
+    // projects we are linking up don't have available ancestors, filter them
+    // out.
+
+    foreach ($projects as $key => $project) {
+      $project_phid = $project->getPHID();
+      if (!isset($all_graph[$project_phid])) {
+        $this->didRejectResult($project);
+        unset($projects[$key]);
+        continue;
+      }
+    }
+
+    if (!$projects) {
+      return array();
+    }
+
     // NOTE: Although we may not need much information about ancestors, we
     // always need to test if the viewer is a member, because we will return
     // ancestor projects to the policy filter via ExtendedPolicy calls. If