Retroactively populate Phriction mailKey column

Summary:
Fixes T6487. Ref T1191. Ref T4029. D10756 introduced, but did not populate, this column. This can cause it to fill with `"\0\0\0..."` after adjustment.

Regardless of the adjustment issue, it's nice to populate this column anyway because there's no fundamental reason an object can't have mail sent about it without being saved first, even though it may not practically be possible in the codebase today.

Test Plan:
  - Ran `storage upgrade`, saw the column populate for older documents.
  - Forced a couple of keys to bad values (too short or with "\0") and saw the migration fix them.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4029, T1191, T6487

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

resources/sql/autopatches/20141107.phriction.popkeys.php

@@ -0,0 +1,29 @@
+<?php
+
+$table = new PhrictionDocument();
+$conn_w = $table->establishConnection('w');
+
+echo "Populating Phriction mailkeys.\n";
+
+foreach (new LiskMigrationIterator($table) as $doc) {
+  $id = $doc->getID();
+
+  $key = $doc->getMailKey();
+  if ((strlen($key) == 20) && (strpos($key, "\0") === false)) {
+    // To be valid, keys must have length 20 and not contain any null bytes.
+    // See T6487.
+    echo "Document has valid mailkey.\n";
+    continue;
+  } else {
+    echo "Populating mailkey for document {$id}...\n";
+    $mail_key = Filesystem::readRandomCharacters(20);
+    queryfx(
+      $conn_w,
+      'UPDATE %T SET mailKey = %s WHERE id = %d',
+      $table->getTableName(),
+      $mail_key,
+      $id);
+  }
+}
+
+echo "Done.\n";