[bug] retry allocation of gen instead of using a lock

The use of a lock to allocate the next generation of a change in couch
backend suffers from at least 2 problems:

1. all modification to the couch database would have to be made through
   a soledad server entrypoint, otherwise the lock would have no effect.

2. introducing a lock makes code uglier, harder to debug, and prone to
   undesired blocks.

The solution implemented by this commit is not so elegant, but works for
what we need right now. Now, concurrent threads updating the couch
database will race for the allocation of a new generation, and retry
when they fail to do so.

There's no high risk of getting blocked for too much time in the while
loop because (1) there's always one thread that wins (what makes the
expected number of retries to be N/2 if N is the number of concurrent
threads), and (2) the number of concurrent attempts to update the user
database is limited by the number of devices syncing at the same time.

0 files changed, 0 insertions, 0 deletions