Implement "words of power" against ApplicationTransactions

Summary:
Ref T2222. Differential has certain "words of power" (like `Ref T123` or `Depends on D345`) which should expand into a separate transaction when they appear anywhere in text.

Currently, they're respected in only some fields. I'm expanding them to work in any remarkup field, including comments and inline comments.

This partially generalizes transaction expansion/extraction in comments. Eventually, I'll probably implement some very soft sort of reference edge for T4036, maybe.

Test Plan: {F119368}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8369
Minor, fix a missing parameter.
Make "EditPro" controller work with diff updates

Summary:
Ref T2222. Make the "EditPro" controller accommodate diff updates, and support the transaction type. This one is pretty straightforward.

Also make `revisionPHID` in the comments table nullable to fix the "Edit" action.

Test Plan:
  - Created new revision.
  - Updated revision.
  - Tried to do some invalid stuff.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8376
Replace "Edit" controller with "EditPro" controller

Summary: Ref T2222. Remove the old controller and swap in the new ApplicationTransactions one.

Test Plan: Made a pile of edits.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8377
Fix some issues where Conpherence would make to many draft requests

Summary:
A few minor fixes:

  - When we build a tag with `"meta" => null`, strip the attribute like we do for all other attributes. Previously, we would actually set the metadata to `null`. This happened with the Conpherence form.
  - Just respond to the draft request with an empty (but valid) response, instead of building a dialog.
  - `PhabricatorShapedRequest` is confusingly named and I should have caught this in review, but the basic shape of it is:
    - You make one object.
    - You call `trigger()` when stuff changes (e.g., a keystroke).
    - It manages making a small number of requests (e.g., one request after the user stops typing for a moment).
  - The way it was being used previously would incorrectly send a request for every keystroke.

I think I'm going to simplify `ShapedRequest` and merge it into some larger queue for T430.

Test Plan: Typed some text, no longer saw a flurry of requests. Reloaded page, still saw draft text.

Reviewers: btrahan, chad

Reviewed By: chad

CC: aran, chad

Differential Revision: https://secure.phabricator.com/D8380
Clean up some Differential behaviors

Summary:
Ref T2222.

  - Restore mail tags for ApplicationTransactions mail.
  - Restore subject line verbs.
  - Denormalize line count and repository PHID.
  - Fix an issue with the mailgun adapter where headers weren't attached properly.

Test Plan: Sent some mail, verified it had correct subjects and tags.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8378
Workboards - add transactions for column changes

Summary:
adds ManiphestTransaction::TYPE_PROJECT_COLUMN and makes it work. Had to clean up the Javascript ever so slightly as it was sending up the string "null" when it should just omit the data in these cases. Ref T4422.

NOTE: this is overall a bit buggy - e.g. move a task Foo from column A to top of column B; refresh; task Foo is at bottom of column B and should be at top of column B - but I plan on additional diff or three to clean this up.

Test Plan: dragged tasks around columns. clicked on those tasks and saw some nice transactions.

Reviewers: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T4422

Differential Revision: https://secure.phabricator.com/D8366
(PhabricatorIRCProtocolAdapter.connect) Use recommended connection registration order from RFC{1459,2812}

http://tools.ietf.org/html/rfc1459.html#section-4.1 and http://tools.ietf.org/html/rfc2812#section-3.1
 mentions that client should send the PASS first, then the latter of NICK/USER.

This is tested and confirmed working with ngircd commit 485d0aec813db9966922f17aae044df2d82b0b67

See: <https://github.com/facebook/phabricator/pull/524>

Reviewed by: epriestley
Check for null, strictly, in maniphest.update param validation

Summary:
If the first non-null entry in the params array is falsey, the request bombs.

Something like {"id":279,"projectPHIDs":[],"status":"0","ownerPHID":"PHID-USER-on3xxsnaljmfn36d4b7a"}

Test Plan:
Before:

  echo '{"id":279,"projectPHIDs":[],"status":"0","ownerPHID":"PHID-USER-cj3cpuh7oorbmnn2pl5g"}' | arc call-conduit maniphest.update
  {"error":"ERR-NO-EFFECT","errorMessage":"ERR-NO-EFFECT: Update has no effect.","response":null}

After:

  echo '{"id":279,"projectPHIDs":[],"status":"0","ownerPHID":"PHID-USER-cj3cpuh7oorbmnn2pl5g"}' | arc call-conduit maniphest.update
  {"error":null,"errorMessage":null,"response":{"id":"279","phid":"PHID-TASK-lbwcq3pmur2c5fuqqhlx"...

Reviewers: garoevans, epriestley, #blessed_reviewers

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8391
Project work boards - make editing tasks from workboards work

Summary: This wasn't working. Create a little JS handler and server-side support for returning the Task in the "project card" format.

Test Plan: Edited tasks from the board - they worked!

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran, chad

Differential Revision: https://secure.phabricator.com/D8392
allow https.cabundle in IRC bot

Summary: Adds support for custom SSL certs in the IRC bot config, same as in .arcconfig

Test Plan: Bot wouldn't connect before. Added this code and corresponding line in bot config,  now it does.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8393
Board feed story - make the task a link too

Summary: looks better, more useful

Test Plan: looked better, was more useful when I observed my feed

Reviewers: chad, epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8394
Link board names to board view in "changed column" stories

Summary: Fixes T4552.

Test Plan:
{F122106}

{F122107}

Reviewers: btrahan, chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T4552

Differential Revision: https://secure.phabricator.com/D8396
Don't actually construct auth providers when checking for their existence

Summary:
A user reported this stack trace:

http://pastebin.com/6auGbZsE

...on this GitHub issue:

https://github.com/facebook/phabricator/issues/389#issuecomment-36612511

The problem is similar to the original report, but not identical. In this case, we're following a sequence of steps like:

  - Run setup checks.
    - Check for enabled providers, in order to raise "no providers configured yet" warning.
      - Try to generate login/redirect URIs.
  - Build the request.
  - Set the default base URI.
  - Run normal code.

Since we try to generate URIs before we provide a default, this fatals. Instead, don't try to build objects.

An alternative fix might be to try to set defaults earlier, but we depend on some config and on building the Request in order to be able to figure out if a request is HTTP or HTTPS right now. We could assume one, or guess, or use protocol-relative URIs (`///host.com`), but I think this fix is a little cleaner overall. If we keep hitting similar stuff, we could look into alternate fixes.

We could also set some kind of "setup mode" flag and make `getURI()` if it's called during setup mode to detect these during testing. I'd like to hit one more of these before doing that, though.

Test Plan: Reproduced the issue, applied the patch, verified this fixes it.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D8395
Maniphest Tasks + Project Boards - some polish

Summary:
Fixes T4550 by changing supportsFeed to shouldPublishFeedStory, so things can be more granular like that are with mail. Attempts to fix things generally too, filtering out xactions that have no business in feed, etc.

Also return an updated Task HTML representation on drag and drop moves, etc. This is important so if the priority changes you can see it reflected in the UI.

Test Plan: dragged tasks around. observed no feed stories on subpriority drags. observed feed stories and updated color bars on stories that changed priority

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T4550

Differential Revision: https://secure.phabricator.com/D8399
Make "My Events" default on Calendar

Summary: Moves Browse to "View All" and makes "My Events" the default on Calendar.

Test Plan: Browse both pages.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8397
Improve ApplicationTransaction behavior for poorly constructed transactions

Summary:
Ref T2222. Five very small improvements:

  - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable.
  - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value.
  - Add an additional check for the other case (shouldn't have a value, but does).
  - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong.
  - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions.

Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4557, T2222

Differential Revision: https://secure.phabricator.com/D8401
Make updates of rejected revisions behave correctly again

Summary:
Ref T2222. Ref T4481. Specifically:

  - When a revision is updated, change all "Reject" reviewers to "Reject Prior".
  - Change status to "Needs Review".
  - Update the state logic to account for this properly.

Test Plan:
  - Created a revision as user A, with B as a reviewer.
  - Rejected as B.
  - Updated the revision as A.
  - Saw revision in "needs review" state, with B as a "Rejected Prior" reviewer.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4481, T2222

Differential Revision: https://secure.phabricator.com/D8402
Add an explcit "Changes Planned" state for Differential

Summary: Ref T2222. Ref T4481. This fixes the issue where "Plan Changes" could immediately trigger a state change (e.g., back to accepted) because of state-based transitions out of the NEEDS_REVISION state.

Test Plan: Planned changes an "accepted" revision, it didn't immediately return to being accepted.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222, T4481

Differential Revision: https://secure.phabricator.com/D8403
Let Herald activation depend on which transactions are being applied, and generate transactions

Summary:
Ref T2222. Ref T4484. This is a stepping stone to getting Herald supported in the new Differental code. Generally:

  - Instead of an Editor either supporting or not supporting Herald, let it choose based on transactions. Specifically, Differential only runs rules on revision creation and diff updates.
  - Optionally, allow an Editor to return some transactions to apply instead of having to apply everything itself. This lets us make it clear why changes happend in the transaction log, and share more code.
  - I updated only one transaction type (owners in Maniphest) since it was the easiest and cleanest to update and test. Everything else still works like it used to, it just won't generate a transaction record yet.
  - The transaction records are a touch rough, but we can clean them up later.

Test Plan: {F122282}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4484, T2222

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