Remove slow file protection updates from launch path

To avoid blocking launch, file protection is now updated async for most
moved files. Out of paranoia, the database files are also update
redundantly on a sync code path.

It's still critical that we update permissions recursively for two
reasons:

1. Updating a containing directories FileProtection does not affect
   existing files in that directory.

2. Because we've changed the containers default file protection level
   (from unspecified to NSFileProtectionComplete), some existing files
   will have there file protection updated upon launching Signal 2.20.
   It's not clear to me which files this affects, and I haven't found
   any relevant documentation, but from observation, it seems to affect
   any top-level files in the container. Regardless, we're now doing the
   right thing: after launching 2.20, ensure all file permissions are
   what we expect.

Also removed no-op file protection on legacy db files. They've already
been moved by the time this method runs in AppSetup.

// FREEBIE

SignalServiceKit/src/Storage/TSStorageManager.m

@@ -155,12 +155,6 @@ void runAsyncRegistrationsForStorage(OWSStorage *storage)
     DDLogInfo(@"%@ \t SHM file size: %@", self.logTag, [OWSFileSystem fileSizeOfPath:self.sharedDataDatabaseFilePath_SHM]);
     DDLogInfo(@"%@ \t WAL file size: %@", self.logTag, [OWSFileSystem fileSizeOfPath:self.sharedDataDatabaseFilePath_WAL]);
 
-    // The old database location was in the Document directory,
-    // so protect the database files individually.
-    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath];
-    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath_SHM];
-    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath_WAL];
-
     // Protect the entire new database directory.
     [OWSFileSystem protectFileOrFolderAtPath:self.sharedDataDatabaseDirPath];
 }
@@ -228,6 +222,19 @@ void runAsyncRegistrationsForStorage(OWSStorage *storage)
 
 + (void)migrateToSharedData
 {
+    // We protect the db files here, which is somewhat redundant with what will happen in
+    // `moveAppFilePath:` which also ensures file protection.
+    // However that method dispatches async, since it can take a while with large attachment directories.
+    //
+    // Since we only have three files here it'll be quick to do it sync, and we want to make
+    // sure it happens as part of the migration.
+    //
+    // FileProtection attributes move with the file, so we do it on the legacy files before moving
+    // them.
+    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath];
+    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath_SHM];
+    [OWSFileSystem protectFileOrFolderAtPath:self.legacyDatabaseFilePath_WAL];
+
     [OWSFileSystem moveAppFilePath:self.legacyDatabaseFilePath
                 sharedDataFilePath:self.sharedDataDatabaseFilePath
                      exceptionName:TSStorageManagerExceptionName_CouldNotMoveDatabaseFile];

SignalServiceKit/src/Util/OWSFileSystem.m

@@ -31,6 +31,7 @@ NS_ASSUME_NONNULL_BEGIN
         success = success && [self protectFileOrFolderAtPath:filePath];
     }
 
+    DDLogInfo(@"%@ protected contents at path: %@", self.logTag, path);
     return success;
 }
 
@@ -147,7 +148,11 @@ NS_ASSUME_NONNULL_BEGIN
         fabs([startDate timeIntervalSinceNow]));
 
     // Ensure all files moved have the proper data protection class.
-    [self protectRecursiveContentsAtPath:newFilePath];
+    // On large directories this can take a while, so we dispatch async
+    // since we're in the launch path.
+    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
+        [self protectRecursiveContentsAtPath:newFilePath];
+    });
 }
 
 + (BOOL)ensureDirectoryExists:(NSString *)dirPath