For backup persitsence, mark the "common ngrams" table as a data table, not an index table

Summary:
Ref T13000. Garbage collecting common ngrams is slow because MySQL isn't all that great at deleting rows quickly. See PHI96, where it looks like it's going to take a week to GC ngrams for a ~million objects at a relatively conservative 0.15 threshold.

In the event of a restore, we can reduce the impact by persisting this table so the ngrams just don't get built when the reindex happens.

Test Plan: Viewed schema in Config, saw common ngrams tables marked as "Data" instead of "Index".

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13000

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

src/applications/config/schema/PhabricatorConfigSchemaSpec.php

@@ -81,12 +81,15 @@ abstract class PhabricatorConfigSchemaSpec extends Phobject {
       $engine->getNgramsSchemaKeys(),
       $index_options);
 
+    // NOTE: The common ngrams table is not marked as an index table. It is
+    // tiny and persisting it across a restore saves us a lot of work garbage
+    // collecting common ngrams from the index after it gets built.
+
     $this->buildRawSchema(
       $engine->getApplicationName(),
       $engine->getCommonNgramsTableName(),
       $engine->getCommonNgramsSchemaColumns(),
-      $engine->getCommonNgramsSchemaKeys(),
-      $index_options);
+      $engine->getCommonNgramsSchemaKeys());
   }
 
   protected function buildRawSchema(