Clarify registration rules more aggressively when configuring auth

Summary: See private chatter. Make it explicitly clear when adding a provider that anyone who can browse to Phabricator can register.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7570
Roadblock users trying to register with external accounts that have invalid emails

Summary:
Ref T3472. Currently, if an install only allows "@mycompany.com" emails and you try to register with an "@personal.com" account, we let you pick an "@mycompany.com" address instead. This is secure: you still have to verify the email. However, it defies user expectation -- it's somewhat confusing that we let you register. Instead, provide a hard roadblock.

(These accounts can still be linked, just not used for registration.)

Test Plan: See screenshot.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3472

Differential Revision: https://secure.phabricator.com/D7571
Improve handling of email verification and "activated" accounts

Summary:
Small step forward which improves existing stuff or lays groudwork for future stuff:

  - Currently, to check for email verification, we have to single-query the email address on every page. Instead, denoramlize it into the user object.
    - Migrate all the existing users.
    - When the user verifies an email, mark them as `isEmailVerified` if the email is their primary email.
    - Just make the checks look at the `isEmailVerified` field.
  - Add a new check, `isUserActivated()`, to cover email-verified plus disabled. Currently, a non-verified-but-not-disabled user could theoretically use Conduit over SSH, if anyone deployed it. Tighten that up.
  - Add an `isApproved` flag, which is always true for now. In a future diff, I want to add a default-on admin approval queue for new accounts, to prevent configuration mistakes. The way it will work is:
    - When the queue is enabled, registering users are created with `isApproved = false`.
    - Admins are sent an email, "[Phabricator] New User Approval (alincoln)", telling them that a new user is waiting for approval.
    - They go to the web UI and approve the user.
    - Manually-created accounts are auto-approved.
    - The email will have instructions for disabling the queue.

I think this queue will be helpful for new installs and give them peace of mind, and when you go to disable it we have a better opportunity to warn you about exactly what that means.

Generally, I want to improve the default safety of registration, since if you just blindly coast through the path of least resistance right now your install ends up pretty open, and realistically few installs are on VPNs.

Test Plan:
  - Ran migration, verified `isEmailVerified` populated correctly.
  - Created a new user, checked DB for verified (not verified).
  - Verified, checked DB (now verified).
  - Used Conduit, People, Diffusion.

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Differential Revision: https://secure.phabricator.com/D7572
Strip +x from some WePay files

Summary: I opened a pull request to fix this in the WePay upstream, see
<https://github.com/wepay/PHP-SDK/pull/13>. Fix it here too now until that
gets pulled.

Auditors: btrahan
Accept case-insensitive mail replies

Summary:
Mailbox sometimes (?) changes the case of the email address (?). Be more liberal in what we accept.

Also fix a minor output bug.

Test Plan: Sent mail to `e1+...` instead of `E1+...`, verified it arrived.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7575
Implement most of the administrative UI for approval queues

Summary:
Nothing fancy here, just:

  - UI to show users needing approval.
  - "Approve" and "Disable" actions.
  - Send "Approved" email on approve.
  - "Approve" edit + log operations.
  - "Wait for Approval" state for users who need approval.

There's still no natural way for users to end up not-approved -- you have to write directly to the database.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7573
Show an "approval queue" item on the home page for admins, and sort out menu item visibility

Summary:
  - If you're an administrator and there are users waiting for approval, show a count on the home page.
  - Sort out the `isUserActivated()` access check.
  - Hide all the menu widgets except "Logout" for disabled and unapproved users.
  - Add a "Log In" item.
  - Add a bunch of unit tests.

Test Plan: Ran unit tests, clicked around as unapproved/approved/logged-in/logged-out users.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Differential Revision: https://secure.phabricator.com/D7574
Implement an approval queue

Summary:
  - Add an option for the queue.
  - By default, enable it.
  - Dump new users into the queue.
  - Send admins an email to approve them.

Test Plan:
  - Registered new accounts with queue on and off.
  - As an admin, approved accounts and disabled the queue from email.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7576
Respect "can edit username" in registration UI

Summary:
Fixes T3741. The flag is respected in terms of actually creating the account, but the UI is a bit unclear.

This can never occur naturally, but installs can register an event which locks it.

Test Plan:
Artificially locked it, verified I got more reasonable UI;

{F81282}

Reviewers: btrahan, datr

Reviewed By: datr

CC: aran

Maniphest Tasks: T3741

Differential Revision: https://secure.phabricator.com/D7577
Fix handle loads in ManiphestTaskListView

Summary:
Fixes T4095. Fixes T3817.

  - The batch editor has some funky handle code which misses projects, share that.
  - Remove some hacks for T3817 that should be good now.

Test Plan: Looked at batch editor, saw projects. Looked at task list.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, martin.schulz

Maniphest Tasks: T3817, T4095

Differential Revision: https://secure.phabricator.com/D7578
Add `bin/repository edit` for CLI repository editing

Summary:
Ref T4039. This is mostly to deal with that, to prevent the security issues associated with mutable local paths. The next diff will lock them in the web UI.

I also added a confirmation prompt to `bin/repository delete`, which was a little scary without one.

See one comment inline about the `--as` flag. I don't love this, but when I started adding all the stuff we'd need to let this transaction show up as "Administrator" it quickly got pretty big.

Test Plan: Ran `bin/repository edit ...`, saw an edit with a transaction show up on the web UI.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4039

Differential Revision: https://secure.phabricator.com/D7579
Prevent Repository local path edit from the web UI

Summary:
Ref T4039. This fixes an issue where a user with the ability to create repositories could view repositories he is otherwise not permitted to see, by following these steps:

  - Suppose you want to see repository "A".
  - Create a repository with the same VCS, called "B".
  - Edit the local path, changing "/var/repo/B" to "/var/repo/A".
  - Now it points at a working copy of a repository you can't see.
  - Although you won't be able to make it through discovery (the pull will fail with the wrong credentials), you can read some information out of the repository directly through the Diffusion UI, probably?

I'm not sure this was really practical to execute since there are a bunch of sanity checks along most/all of the major pathways, but lock it down since normal users shouldn't be editing it anyway. In the best case, this would make a mess.

Test Plan: {F81391}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4039

Differential Revision: https://secure.phabricator.com/D7580
Fix new logged-out "Login" button URI and workflowiness

Summary: Whelp apparently I never actually clicked this.

Auditors: btrahan
Cache the computation of the custom block component of the markup key

Summary:
Caught this taking way too long on a production profile:

https://secure.phabricator.com/xhprof/profile/PHID-FILE-vfzq3sregh5xvpf5nc2t/?symbol=PhabricatorMarkupEngine::getMarkupFieldKey

Cache it; it's always identical.

Test Plan: Loaded Conpherence locally.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7583
Land to GitHub + support stuff

Summary:
A usable, Land to GitHub flow.

Still to do:
- Refactor all git/hg stratagies to a sane structure.
- Make the dialogs Workflow + explain why it's disabled.
- Show button and request Link Account if GH is enabled, but user is not linked.
- After refreshing token, user ends up in the settings stage.

Hacked something in LandController to be able to show an arbitrary dialog from a strategy.
It's not very nice, but I want to make some more refactoring to the controller/strategy/ies anyway.

Also made PhabricatorRepository::getRemoteURIObject() public, because it was very useful in getting
the domain and path for the repo.

Test Plan:
Went through these flows:
- load revision in hosted, github-backed, non-github backed repos to see button as needed.
- hit land with weak token - sent to refresh it with the extra scope.
- Land to repo I'm not allowed - got proper error message.
- Successfully landed; Failed to apply patch.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T182

Differential Revision: https://secure.phabricator.com/D7555
Merge branch 'master' of http://github.com/facebook/phabricator