Application Emails - make various user email editing paths respect application emails

Summary: Ref T3404. The only mildly sketchy bit is these codepaths all load the application email directly, by-passing privacy. I think this is necessary because not getting to see an application doesn't mean you should be able to break the application by registering a colliding email address.

Test Plan:
Tried to add a registered application email to a user account via the web ui and got a pretty error.
Ran unit tests.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T3404

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

src/applications/auth/controller/PhabricatorAuthRegisterController.php

@@ -62,6 +62,18 @@ final class PhabricatorAuthRegisterController
     if (!PhabricatorUserEmail::isValidAddress($default_email)) {
       $default_email = null;
     }
+    if ($default_email !== null) {
+      // We should bypass policy here becase e.g. limiting an application use
+      // to a subset of users should not allow the others to overwrite
+      // configured application emails
+      $application_email = id(new PhabricatorMetaMTAApplicationEmailQuery())
+        ->setViewer(PhabricatorUser::getOmnipotentUser())
+        ->withAddresses(array($default_email))
+        ->executeOne();
+      if ($application_email) {
+        $default_email = null;
+      }
+    }
 
     if ($default_email !== null) {
       // If the account source provided an email, but it's not allowed by
@@ -86,7 +98,6 @@ final class PhabricatorAuthRegisterController
       // If the account source provided an email, but another account already
       // has that email, just pretend we didn't get an email.
 
-      // TODO: See T3340.
       // TODO: See T3472.
 
       if ($default_email !== null) {