Transactions - change show all key from "~" to "@"

Summary: (some) international keyboard layouts can not type "~" in a way as to trigger this so use "@" instead. Save the suggested "+" as that seems like it would be useful for some future "adding stuff" keyboard workflow. Pretty stoked to get this squared away as I am quite confident our unreleased product will now be a huge smashing success. Ref T6683.

Test Plan: made sure my choice was okay via https://en.wikipedia.org/wiki/Dead_key#Dead_keys_on_various_keyboard_layouts; used the "@" key to show all transactions

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6683

Differential Revision: https://secure.phabricator.com/D10983
Phriction - validateTransactions that need parent ancestry to complete successfully

Summary:
Fixes T6651, T6682. Since policy is defined by ancestry, you can't make things outside the core tree.

An alternative fix would be to automagically stub everything in these cases. This has potential negative policy implications - consider making a public document with several levels of depth that automagically stubs out its ancestry as public - and additionally the PhabricatorApplicationTransactionEditor framework would make this very tricky code (i.e. you are expected to validateTransactions in said hook *and* return an error if things aren't valid and not do some automagic stubbing, etc.)

Test Plan: tried to move a doc from location/that/exists to locationz/thatz/dontz/existz/ and got an error message with links to each missing doc. tried to create a doc at locatonz/thatz/dontz/existsz/ and got an error message with links to each missing doc.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6682, T6651

Differential Revision: https://secure.phabricator.com/D10978
Home - limit "status" queries to 100 and show 99+ if we hit that

Summary: Fixes T6595. This diff has two issues as is... 1) the differential data fetching is pretty cheesey, but it looks like we can't just issue three separate databases to get the right data? 2) the translations break, since I am turning this into a string (and not an int) so the whole pluralization bit fails. I think 1 is okay as is and 2 needs to be fixed though I am not sure how to best do that...

Test Plan: loaded home page and it looked nice...!

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6595

Differential Revision: https://secure.phabricator.com/D10979
Allow repositories to be bound to an AlmanacService

Summary:
Ref T2783. This is primarily exploratory and just figuring out what we're blocked on:

  - Allow a Repository to be bound to a Service. The Service may eventually define multiple read/write nodes, etc.
    - There's no UI to do this binding yet, you have to touch the database manually.
  - If a repository is bound to a Service, effect Conduit calls via calls to the remote service instead of executing them in-process.
    - These don't actually work yet since there's no authentication (see T5955).

Test Plan:
  - Made a nice Service with a nice Binding to a nice Interface on a nice Device.
  - Force-associated a repository with the service using a raw MySQL query.
  - Saw Phabricator try to make a remote call to the service (on localhost) and fail because of missing auth stuff.
  - Also ran `almanac.queryservices`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2783

Differential Revision: https://secure.phabricator.com/D10982
Restore Maniphest subscriber transaction mail tag

Summary: Fixes T6748. This just didn't get aligned when CCs became a modern transaction.

Test Plan: Added a CC to a task, used `bin/mail show-outbound` to verify it showed up as a CC tag.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T6748

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