Concurrent replication tasks lead to racy transactional voting

ReplicateRepository is replicating the gitconfig, gitattributes and repository concurrently. Because all of these nowadays write data with transactional voting enabled this leads to an indeterminate order of votes depending on which action is fastest. The transaction code detects this race as expected, but the result is that replication fails.

We can easily fix this issue by making the replication tasks sequential. Parallelization of this task only brought us problems in the past, and it really is a premature optimization: both gitconfig and gitattributes are tiny files, so it shouldn't ever take long to synchronize them. Syncing the repository state involves multiple RPC calls and Git commands though and can take minutes to complete, so shedding a few milliseconds by parallelizing these tasks is not worth it at all in the general case.