[migration] Fix race-condition in account migration dealing with stopping / starting syncs on separate hosts.

Summary:
There is a race-condition dealing with migrating an account between
two separate hosts. This manifests itself in the following scenario:

- An account is syncing on 'Host A' (so 'sync_host' is set to 'Host A')
- The account is effectively migrated to 'Host B' (by either stopping the
  account and starting it again and it gets 'work stolen' by 'Host B', or
  potentially by simply changing the sync_host in the future)
- 'Host B' starts syncing the account right away, changing the 'sync_host'
  property on the account to be 'Host B'
- 'Host A' then tries to stop syncing the account. In this process, it checks
  to see if the account.sync_host matches it's own FQDN (assertion)
- This assertion fails, and therefore 'stopping the account' never happens.

As a consequence, this account remains in the 'self.monitors' list on 'Host A'
and during each iteration, 'Host A' realizes that it should remove the account
from it's list of monitors and repeats the process.

Furthermore, if the account is stopped, the sync_host is set to 'None' which
also does not match 'Host A' so this sync-engine doesn't get out of this loop.

Finally, if the account is started again and 'Host A' would have an opportunity
to re-claim the account, this also is not possible as the assertion prevents the
lock-file from being removed therefore preventing a new-sync from ever starting
again on this host.

The solution to this is that if the sync is set to be stopped and the sync_host
matches the FQDN the same code runs as before. If the sync_host doesn't match
the FQDN, then 'Host A' in the above scenario should log a warning and then
stop syncing the account, kill all monitors and remove the local lock. It
should not set the state to 'stopped' for the scenario when the account has
been migrated to a different host.

Note that account migration still has some potential issues and special attention
needs to be taken for when this occurs. Especially in regards to oustanding
sync-back actions. However, in the situation where the account is effectivly
in a steady-state, this change should allow the account to be migrated between
sync-engines.

Test Plan: Review the code.

Reviewers: emfree

Reviewed By: emfree

Differential Revision: https://review.inboxapp.com/D513