Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang,baku

It appears that the issue is caused by a change in behaviour from bug
1799470 which made the profile available earlier during startup. If the
permission manager is started between the time when the profile becomes
available and profile-do-change, it would've previously initialized
without storage, and initialized storage after profile-do-change, but
after the changes it may initialize twice instead.

This patch changes the profile-do-change handler to check if we already
have a profile, and avoid initializing the DB twice in that situation.

Differential Revision: https://phabricator.services.mozilla.com/D173062

extensions/permissions/PermissionManager.cpp

@@ -2584,8 +2584,9 @@ NS_IMETHODIMP PermissionManager::Observe(nsISupports* aSubject,
                                          const char16_t* someData) {
   ENSURE_NOT_CHILD_PROCESS;
 
-  if (!nsCRT::strcmp(aTopic, "profile-do-change")) {
-    // the profile has already changed; init the db from the new location
+  if (!nsCRT::strcmp(aTopic, "profile-do-change") && !mPermissionsFile) {
+    // profile startup is complete, and we didn't have the permissions file
+    // before; init the db from the new location
     InitDB(false);
   } else if (!nsCRT::strcmp(aTopic, "testonly-reload-permissions-from-disk")) {
     // Testing mechanism to reload all permissions from disk. Because the