Support looking up generic package registry files by sha256 hash and file name

What does this MR do and why?

Adds a new endpoint to generic packages to lookup files by group, sha256 hash and file name like some other registries do: GET /api/v4/groups/:id/packages/generic/:sha256/:file_name. This supplements the already existing GET /api/v4/projects/:id/packages/generic/:package_name/:package_version/:file_name.

This change makes it much easier to lookup packages where the project a package is stored in may not be known, for example I'm developing gitlab-cargo-shim to integrate a GitLab's registry with Rust's cargo. Cargo has only one global configurable parameter for a whole registry, dl, which defines the format of the URL.

dl: This is the URL for downloading crates listed in the index. The value may have the following markers which will be replaced with their corresponding value:

• {crate}: The name of crate.
• {version}: The crate version.
• {prefix}: A directory prefix computed from the crate name. For example, a crate named cargo has a prefix of ca/rg. See below for details.
• {lowerprefix}: Lowercase variant of {prefix}.
• {sha256-checksum}: The crate's sha256 checksum.

Using this MR, the dl URL can be defined as

"dl": "https://gitlab.com/api/v4/groups/[our-group]/packages/generic/{sha256-checksum}/{crate}-{version}.crate?private_token=[the-users-impersonation-token]",

I think this flexibility will be a massive advantage to have for other third-party package managers.

How to set up and validate locally

Setup an API token and run:

export PRIVATE_TOKEN=my-private-token
echo "Hello world" | curl --upload-file - --header "Private-Token: $PRIVATE_TOKEN" http://127.0.0.1:3000/api/v4/projects/6/packages/generic/my-package/1.0/test.txt
curl --header "Private-Token: $PRIVATE_TOKEN" http://127.0.0.1:3000/api/v4/groups/flightjs/packages/generic/1894a19c85ba153acbf743ac4e43fc004c891604b26f8c69e1e83ea2afc7c48f/test.txt

And with a bit of luck your output is Hello world\n

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.