Attempt to fix changeset replication lock queueing.

When the changeset replication runs slow, a lot of processes queue up trying to get the lock. I'm not totally sure, but it looks like they then get woken up in a random order, resulting in weird out-of-order behaviour.

This patch simplifies that process in two ways:

1. If the lock isn't acquired, the process exits. This means much less (perhaps zero) lock queueing.
2. Using a separate `lockfile`, rather than the current state file. Since the new state file is moved into place over the old one, it was effectively unlocking at that point for _new_ processes. But would also unblock an old process which still had the old (now unlinked) file descriptor open.

Hopefully between these two changes, it resolves some of the brokenness that plagues changeset replication! :-)