repository: Fix indetermenistic voting order in ReplicateRepository

When replicating repositories we not only synchronize the repo's references, but also have to synchronize the gitconfig and gitattributes files. To speed up replication a bit we perform these tasks in parallel. This has the consequence that because all of the tasks perform voting on the data they're about to change, the order in which the votes arrive at Praefect is not deterministic. As a result, we see that transactions get cancelled.

Fix this bug by not running those tasks in parallel anymore. This is a premature optimization anyway: neither the gitconfig nor gitattributes files should be big in the general case, so replicating those files should be a matter of milliseconds. And this is supported by production data: P99 of the GetConfig RPC is 1.13ms, and GetInfoAttributes has a P99 of 0.98ms. In contrast to that, replicating the references and objects is ranging in the hundreds of milliseconds or even dozens of seconds. Saving about two milliseconds there just isn't worth it.

Changelog: fixed

Fixes #4036 (closed)