Use accounts typeahead endpoint for project membership

Reviewed by: epriestley

See: <https://github.com/facebook/phabricator/pull/436>
Fix 404 clicking Find Owners in diffusion, if Owners application is disabled.

Test Plan: Install/uninstall Owners application, Find Owners action shown/hidden as expected.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7557
Replace some hsprintf() by phutil_tag()

Test Plan: Looked at a diff with inline comment.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7549
Fix an issue where Ponder rename stories tried to render question bodies

Summary: Missing some `break;`, pretty sure this is causing the issue on `secure.phabricator.com`.

Test Plan: Will push.

Reviewers: chad, btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7559
Generalize SSH passthru for repository hosting

Summary:
Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN.

For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`.

The way this will work is:

  - The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects.
  - The `willWriteCallback` will look at those messages and determine if they're reads or writes.
    - If they're writes, it will check for write permission.
    - If we're good to go, the message object is converted back into a byte stream and handed to the underlying command.

Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo).

Reviewers: btrahan

Reviewed By: btrahan

CC: hach-que, asherkin, aran

Maniphest Tasks: T2230

Differential Revision: https://secure.phabricator.com/D7551
Fix an issue where PHP puts the content type in CONTENT_TYPE instead of HTTP_CONTENT_TYPE

Summary: Fixes T4084. See that task for discussion.

Test Plan: Did `git clone`. My setup doesn't precisely reproduce the original issue, but hopefully @enko can confirm this is a fix.

Reviewers: btrahan, enko

Reviewed By: enko

CC: enko, aran

Maniphest Tasks: T4084

Differential Revision: https://secure.phabricator.com/D7561
Fix `--depth N` clones in Git

Summary: Ref T2230. Fixes T4079. As it turns out, this is Git being weird. See comments for some detials about what's going on here.

Test Plan: Created shallow and deep Git clones.

Reviewers: hach-que, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4079, T2230

Differential Revision: https://secure.phabricator.com/D7554
Enable Mercurial reads and writes over SSH

Summary:
Ref T2230. This is substantially more complicated than Git, but mostly because Mercurial's protocol is a like 50 ad-hoc extensions cobbled together. Because we must decode protocol frames in order to determine if a request is read or write, 90% of this is implementing a stream parser for the protocol.

Mercurial's own parser is simpler, but relies on blocking reads. Since we don't even have methods for blocking reads right now and keeping the whole thing non-blocking is conceptually better, I made the parser nonblocking. It ends up being a lot of stuff. I made an effort to cover it reasonably well with unit tests, and to make sure we fail closed (i.e., reject requests) if there are any parts of the protocol I got wrong.

A lot of the complexity is sharable with the HTTP stuff, so it ends up being not-so-bad, just very hard to verify by inspection as clearly correct.

Test Plan:
  - Ran `hg clone` over SSH.
  - Ran `hg fetch` over SSH.
  - Ran `hg push` over SSH, to a read-only repo (error) and a read-write repo (success).

Reviewers: btrahan, asherkin

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2230

Differential Revision: https://secure.phabricator.com/D7553
Support serving SVN repositories over SSH

Summary:
Ref T2230. The SVN protocol has a sensible protocol format with a good spec here:

http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol

Particularly, compare this statement to the clown show that is the Mercurial wire protocol:

> It is possible to parse an item without knowing its type in advance.

WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL

Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed.

It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them.

Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc).

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2230

Differential Revision: https://secure.phabricator.com/D7556
Wait for the Git client to disconnect before exiting in Git SSH workflows

Summary:
Ref T2230. Very rarely, even though we've flushed the connection and sent all the data, we'll close the connection before Git is happy with it and it will flip out with an error like this:

  fatal: The remote end hung up unexpectedly
  fatal: early EOF
  fatal: index-pack failed

This is hard to reproduce because it depends on the order of read/write operations we can't directly control. I only saw it about 2% of the time, by just running `git pull` over and over again.

Waiting for Git to close its side of the connection seems to fix it.

Test Plan: Ran `git clone` a ton of times without seeing the error again. Ran `git push` a ton of times with new commits.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2230

Differential Revision: https://secure.phabricator.com/D7558
Herald - add ability to conditionalize on Maniphest Task projects

Summary: adds FIELD_PROJECTS and deploys it to Maniphest Task Herald Adapter. Went with "projects" because it feels like that could go well in other Adapters that want to conditionalize based on project.

Test Plan: made a new herald rule to be cc'd if project foo was on a task. it worked!

Reviewers: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7564
Add arcanist project phid to differential.query

Summary: Fixes T3535. Also, flip flop on that spacing thing and make the spaces purdy

Test Plan: got an arcanist projected phid in the json dict

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T3535

Differential Revision: https://secure.phabricator.com/D7565
Maniphest - fix a bug when selecting all tasks and then dragging them around

Summary: Fixes T4006.

Test Plan: clicked "select all" and dragged around tasks. Noted the task remained selected as I re-ordered, thus keeping hte count accurate. Verified when I hit "batch edit" the right tasks showed up.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T4006

Differential Revision: https://secure.phabricator.com/D7566
Remove `differential.anonymous-access`

Summary:
Fixes T3034. This is obsoleted by modern policies.

This was written by a Facebook intern and is rarely used -- the Hive install might be the only use in the wild. It has never really worked correctly.

Test Plan: `grep`; browsed Differential.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3034

Differential Revision: https://secure.phabricator.com/D7568
Don't implement SVN over HTTP

Summary:
Ref T2230. As far as I can tell, getting SVN working over HTTP is incredibly complicated. It's all DAV-based and doesn't appear to have any kind of binary we can just execute and pass requests through to. Don't support it for now.

  - Disable it in the UI.
  - Make sure all the error messages are reasonable.

Test Plan: Tried to HTTP an SVN repo. Tried to clone a Git repo with SVN, got a good error message.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2230

Differential Revision: https://secure.phabricator.com/D7562
Don't allow "autoclose only" to be set in Mercurial

Summary: We don't actually support this yet, so hide the configuration.

Test Plan: Edited branches for an hg repo.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7563
Remove one remaining "differential.anonymous-access"

Fixes T4091.

Auditors: btrahan
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