Remove unrelated change

This may mostly have been covered by D20469, although that change does not extend to reverting/reopening tasks.

This stuff is largely resolved, but survived by a few remaining issues in T13290.

Not actively working on this.

Moving this to [[https://github.com/freelancer/flarc | flarc]].

Moving this to [[https://github.com/freelancer/flarc | flarc]].

Not actively working on this.

Not actively working on this.

This code is gone.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

Not actively working on this.

I'll hold this until after the release cut anyway since errors here are unusually dangerous (they can lead to XSS very easily), but I think it would also be hard to get this wrong without breaking a lot of unit tests and UI behavior in fairly obvious ways.

• Choose less-misleading constants and notations for the examples.
• Rewrite the example documentation to more clearly follow the new execution flow.
• Clarify the "child tokens appear first" explanation.
• Make encountering an invalid token ("01234" or "99999") throw. It should be impossible for invalid tokens to appear anywhere.
• Make encountering an out-of-order token (for example, token 30 while we're processing token 20) throw. It should be impossible for out-of-order tokens to appear anywhere.

I've been staring at this long enough that I can plausibly claim to understand how it works. Put this on the pile of "terrible interview questions that I'm sure someone somewhere is getting asked".

In either case, not an API change, just a nomenclature change.

I only blamed around a little bit, but I'm nearly certain they were named incorrectly from the beginning.

Doing this right (or, at least, more right) is probably about 20 lines of code and would make transaction.search a little more useful, so I may just take a stab at it at the end of this series.

Since shouldDisplayGroupWith() includes a 2-minute cutoff and requires transactions have the same author, and we merge transactions that are part of the same edit before applying them (so if you submit 100 "edit title" transactions at the same time, we only actually apply the last one, since none of the others have any effect) I think you could only generate a group with 100+ transactions by writing a script that repeatedly edited the same field to different values very quickly. This seems very unlikely, even given the great ambition I ascribe to our users.

Oh, the relevance is that PhabricatorDatasourceEngineExtension now handles "doing magic stuff when you type things into the global search bar" (like jumping to a task when you type T123), and the next change was making "type a URI" mean "navigate to that uri" -- which got a mention in T5378, although it isn't the primary focus of that task.