Rewrite relative paths in Coordinator

The repositories table has a replica_path column to store where the replicas are stored on the disks of the Gitaly nodes. While currently the replica_path is always the same as the relative_path the client uses to access the repository, this will change soon. Praefect will generate unique relative paths for repositories solve two problems:

1. If a repository is deleted and then recreated on the cluster, the stale state from the earlier repository may cause problems or prevent the operation entirely. This is currently impacting backup restorations (#3546 (closed)) which first delete the repository from the cluster and then restore from the backup. With replica_path decoupled from the relative_path, Praefect can store the new repository in a different path which prevents the old state from conflicting with the newly recreated repository.

2. The repositories stored on the cluster may be renamed. As the relative_path must currently match the disk path of the repository, Praefect needs to move files on disk and update database records. If one of these operations fail, the repository will end up in a weird in-between state. With the replica_path decoupled, the relative_path is only used as an external name the client uses to refer to the repository. As such, renames can be done atomically by updating the relative_path in the database without having to move any repositories on the disks.

The replica_path has been set since 14.4 for every repository. This MR updates the cooridnator to proxy RPCs at the replica_path instead of the relative path in the request. This ensures that backwards compatibility when Praefect begins one release later generating unique paths for repositories.

This MR only covers the cooridnator, a separate MR will handle replication operations.