Partition fork with source repository in CreateFork

Gitaly's TransactionManager requires all object pool members to be in the same partition. Currently we're ensuring doing that generally by extracting the additional repository from the request and ensuring the target repository of the RPC gets partitioned with it. Additional repository is used in the ObjectPoolService's RPCs to tag the other repository being accessed in the pool related operations, and it may be either the object pool or one of the member repositories depending on the RPC.

When a repository is first accessed, we also check whether it has an existing alternate link on the disk, and place the repository in the same partition with its alternate if so.

These two methods are enough to ensure in general the pools and their members get partitioned together. One execption to this is CreateFork. The created fork should be placed in the same partition as the origin repository as they'll both eventually be connected to the same pool. CreateFork does not tag the source repository as an additional repository so the general handling does not apply for it. Tagging it as the additional repository won't work with Praefect as Praefect rewrites the paths of additional repositories. The additional repository is fetched through the API so it needs to have its original relative path intact.

This commit introduces special handling for CreateFork. The transaction middleware checks whether the request is a CreateForkRequest. If so, the source repository is extracted and the newly created fork gets partitioned with it.

Along with the behavior changes, we add a test that exercises the entire fork creation flow as typically done. Tursn out Gitaly didn't a test covering the scenario at all.

Closes #5762 (closed)