Unify Partition ID Usage with PartitionKey

Summary

Based on the proposal in MR !7977, comment, this issue tracks the implementation of using PartitionKey as the primary partition identifier across all Gitaly components, replacing the current dual approach of partitionID vs partitionKey for RAFT-enabled vs non-RAFT deployments.

Background

Gitaly's partition identification system has evolved as part of the RAFT architecture implementation. The RAFT architecture requires globally unique identifiers that work across distributed nodes, leading to the introduction of hashed composite keys. Because using partition sequencer alone within each node doesn't guarantee unique partition IDs. RaftPartitionKey is a globally-unique identifier for a replicated partition. The replica which minted the partition is responsible for computing the RaftPartitionKey, which is a hash of the storage name and partition ID.

In the current plan, when a partition is replicated to a new node, the node will assign the next available partition ID from its sequencer, disregarding the original ID of the partition (Because we can not guarantee that sequencers will be in sync). Therefore computed PartitionKey from the original node will be shared with the replicated node and will be used as a routing table to point to the correct partition ID.

This approach creates complexity for features like backups, restores, and general partition management across different deployment modes:

1. Backup Path Complexity: RAFT and non-RAFT architectures use different means to refer to partitions, requiring backup systems to be aware of deployment mode to be able to refer to correct backup image from object storage.
2. Cross-Mode Restore Issues: Cannot easily restore a backup taken while RAFT was enabled onto a non-RAFT instance or vice versa
3. Multiple Mapping Tables: Need to maintain relativePath -> partitionID mapping AND partitionKey -> partitionID mapping
4. Feature Duplication: In the future any time we need to storage things with partition ID as a path will require RAFT-aware and non-RAFT code paths.

Proposed Solution

Replace partitionID usage directly with partitionKey in the core of partition manager. Which means instead of using uint64 value taken from partitionAssigner as ID, we will generate the partitionKey from it and use that as the partition ID. Since it is generated from storageName + ID combination, it will guarantee the uniqueness of the partitionID across any RAFT node, and therefore we won't need to keep additional routing table.