fsmonitor: acquire localrepo.wlock prior to emitting hg.update state we see some weird things in the watchman logs where the mercurial process is seemingly confused about which hg.update state it is publishing through watchman. On closer examination, we're seeing conflicting pids for the clients involved and this implies a race. To resolve this, we extend the wlock around the state-enter/state-leave events that are emitted to watchman. Test Plan: Some manual testing: In one window, run this, and then checkout a different rev: ``` $ watchman -p -j <<<'["subscribe", "/data/users/wez/fbsource", "wez", {"expression": ["name", ".hg/updatestate"]}]' { "version": "4.9.0", "subscribe": "wez", "clock": "c:1495034090:814028:1:312576" } { "state-enter": "hg.update", "version": "4.9.0", "clock": "c:1495034090:814028:1:312596", "unilateral": true, "subscription": "wez", "metadata": { "status": "ok", "distance": 125, "rev": "a1275d79ffa6c58b53116c8ec401c275ca6c1e2a", "partial": false }, "root": "/data/users/wez/fbsource" } { "root": "/data/users/wez/fbsource", "metadata": { "status": "ok", "distance": 125, "rev": "a1275d79ffa6c58b53116c8ec401c275ca6c1e2a", "partial": false }, "subscription": "wez", "unilateral": true, "version": "4.9.0", "clock": "c:1495034090:814028:1:312627", "state-leave": "hg.update" } ``` Tailed the watchman log file and looked for invalid state assertion errors, then ran my `rebase-all` script to update/rebase all of my heads. Didn't trigger the error condition (but couldn't reliably trigger it previously anyway), and the output captured above shows that the states are being emitted correctly.