Up to now, only updates of groups which don't modify the name succeeded
when their execution overlapped somehow. As we keep a record of all the
group names on a dedicated branch, any concurrent modifications of a
group name (may that either creating a new group or renaming an existing
one) would result in a LockFailureException for one of the
modifications.
To circumvent this, we now retry group creations or updates whenever we
receive a LockFailureException.
As deterministically testing this situation is a bit tricky, we need to
cheat a bit to generate it: We include a member modification in the
creation/update which doesn't change the members but creates another
group while the original creation/update is in progress. Even though
using a side-effect during a member modification is heavily discouraged,
we make an exception for these tests in order to not add special
test-only code to GroupsUpdate.
Change-Id: Ie65aeb40f27b7734c2f99dc0bb8fdf86a04570f1
e3cc82d2f8