Update relative path in SetGeneration

Praefect previously allowed multiple replica records of a single repository on a storage. This was possible if the repository was renamed, as the primary key was the repository's virtual storage and relative path. When the repository was renamed, the replica records that were not yet renamed were considered to be a different repository. Usually this disparity would be fixed by the rename replication job Praefect would schedule on renaming. If the job failed, the repository would be left in it's old path. The reconciler would eventually replicate the repository to the new path from another Gitaly node.

Praefect is now using repository IDs and is enforcing that each Gitaly node has a single copy of a repository due to the uniqueness of the repository ID. This causes problems with the above flow as the replica left at the old path would have the same repository ID as the new replica reconciler is replicating to. This is causing problems on staging where some repositories had only some of the replicas renamed and the reconciler is now facing unique constraint issues when attempting to reconcile the repository to the new location. After the migration to unique relative paths is completed, this won't really be an issue anymore as we don't be moving the repositories on disks anymore and the renames are done atomically in the database. For now though, Praefect needs to workaround this by updating the replicas record to point to the relative path the replication job contained.

Fixes #3876 (closed)