Support directory structure in generic package registry

Attribution

The MR followed a similar approach to the one used in Resolve "Packaging: Support directory structure" (!141361 - merged).

🔭 Context

Users can publish their generic packages to GitLab's Generic Package Repository. However, it has a limitation: it doesn't support publishing directory structured files.

Directory structured files simply mean files that are named to follow a directory structure. So if we have a file named directory/subdirectory/file.txt, and the user tried to publish it to the Generic Package Repository, it would fail.

What does this MR do and why?

Enables creating package files with files that belong to a directory, saving the directory as a URL encoded version of the file name.

The following Generic Package Repository's endpoints are modified to accept an optional path parameter:

• workhorse authorization endpoint: PUT /api/v4/projects/:id/packages/generic/:package_name/:package_version/(*path)/:file_name/authorize
• Upload endpoint: PUT /api/v4/projects/:id/packages/generic/:package_name/:package_version/(*path)/:file_name
• Download endpoint: GET /api/v4/projects/:id/packages/generic/:package_name/:package_version/(*path)/:file_name

So, if we are uploading/downloading a package with a file named directory/subdirectory/file.txt, then the optional path param would capture directory/subdirectory as the path, and the file_name param would capture file.txt.

The path & file_name params are concatenated & encoded, then we store the file full path as the name of the file in the packages_package_files database table. That means the value of the column file_name in the database will be directory%2Fsubdirectory%2Ffile.txt.

When a directory structured file is downloaded from the UI, we remove the directory structure from its full path and just keep the name itself. So the file directory/subdirectory/file.txt will be renamed as file.txt when downloaded from the UI.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

How to set up and validate locally

1. Create any dummy file with dummy content and name it path/to/file.txt.
2. Publish it to a project:

curl --header "PRIVATE-TOKEN: <your_access_token>" \
     --upload-file path/to/file.txt \
     "http://gdk.test:3000/api/v4/projects/<project_id>/packages/generic/my_package/0.0.1/path/to/file.txt"

3. Navigate to the UI page of the project's package registry. The file should show in the UI as in the above screenshot.
4. Download the file from the UI or using the API:

curl --header "PRIVATE-TOKEN: <your_access_token>" \
     "http://gdk.test:3000/api/v4/projects/<project_id>/packages/generic/my_package/0.0.1/path/to/file.txt"

5. The file should be downloaded normally.

Related to #454705 (closed)