Fix repository archive generation when hashed storage is enabled

What does this MR do?

Uses the correct archive prefix when hashed storage is enabled

Are there points in the code the reviewer needs to double check?

My intent here was to keep the diff as small as possible, since we'd like it in 11.0. This means that I didn't make a large number of very sensible refactorings; I intend to open issues for them:

• Remove Gitlab::Git::Repository#name altogether: https://gitlab.com/gitlab-org/gitlab-ce/issues/47341
• Move archive_metadata and friends out of Repository altogether
• Pass Project#full_path to Gitlab::Git::Repository on initialization (it's passed in in a couple of places)
• Audit other users of Gitlab::Git::Repository#relative_path or #name for problems: https://gitlab.com/gitlab-org/gitlab-ce/issues/47342
• ...

Why was this MR needed?

Without this, the "download .tar.gz" links for a project with hashed storage do not work as expected. The wrong filename is used for the archive, and the top-level member within the archive has the wrong name. This will break using these archives as build/deployment artifacts, which is very common (omnibus-gitlab, a large number of archlinux recipes, etc), which blocks enabling hashed storage as a consequence.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Tests added for this feature/bug
• Conform by the code review guidelines
  • Has been reviewed by a Backend maintainer
• Conform by the merge request performance guides
• Conform by the style guides
• If you have multiple commits, please combine them into a few logically organized commits by squashing them
• Internationalization required/considered
• End-to-end tests pass (package-and-qa manual pipeline job)

What are the relevant issue numbers?

Closes #45702 (closed)