Rework locking in ringpop-go

[motiejus]

Locking in ringpop-go is too granular, and is giving us headaches:

1. There are many module-level and datastructure-level locks which are difficult to reason about. That makes it difficult to refactor anything that changes way the critical sections are locked, and is hard to do right without adding new race conditions or deadlocks (ask @motiejus).
2. When we need to fix a race condition that we know about, to avoid (1), we fall back into adding yet another lock. For example, see Fix race in membership and ring consistency #112.

To fix this, we agreed to do the following:

1. Make locking much more coarse: ideally, only one lock in Ringpop. The lock would be acquired when ringpop code is entered via API or network call (and released when a network call is made). That way we would know that whenever ringpop is mutating or reading its state, the lock is locked.
2. Remove all the other locks.
3. Win!