Simpler (and hopefully better) rebase detection
Simpler (and hopefully better) rebase detection

Summary:
Documented much of the motivation in a comment, but I'll put in here too:

== GOAL ==

We want to know when an N-files-changed notification is due to the user changing
their mergebase with master. This could be due to pulling master & rebasing their
work onto the new master, or just moving from one commit to another.

== PREVIOUS SOLUTION ==

Unfortunately, Watchman's mercurial integration is racy and not to be trusted.
Previously we tried this:

1. Keep a count of how many transactions are currently in progress
2. When hg.update ends, wait for the transaction count to drop to 0
3. When there are 0 in-progress transactions, then query for the mergebase

This worked pretty well, but looking at some logs I would see step 3 would not
always fire. Maybe we were missing some state_leave notifications. Also, the
source control people aren't confident that waiting for the transactions to
is a strong guarantee.

== CURRENT SOLUTION ==

So this is a more simple solution. It's based around the assumption that once
Watchman tells us that N files have changed, things have settled down enough
that it's safe to query for the mergebase. And since querying for the mergebase
is expensive, we only do so when we see an hg.update. After an hg.update it's
more acceptable to delay a file-changed notification than after a user saves a
file in the IDE

Reviewed By: jbrown215

Differential Revision: D17764319

fbshipit-source-id: 743bdef351eb897ee57818dd5d6bba97c945ba85

nmote/flow,nmote/flow,nmote/flow,nmote/flow,nmote/flow,nmote/flow,nmote/flow