Revert auth changes on the Composer registry package endpoint

Context

Composer packages are not files as other package formats. Composer packages are actually simply git tags.

Under this perspective:

1. publishing a composer package is actually creating a git tag.
2. pulling a composer package is downloading the git tag. Basically, it's download the source code zip archive. We have such button in the GitLab UI. Browse a git tag and you will see in the upper right hand side a button to download the zip file of that tag.

Now, the GitLab Composer Package Registry was implemented to use the Package registry a bit as a cache. It will host those zip files as package files, this way when $ composer asks for a download url for a package name + version, we can simply point to the package file.

This is ok but how do we create those package files? Well, we created a simple endpoint that users will need to ping to "create" or put the git tag into the package registry.

When that endpoint was implemented we accepted the usual token types: PATs, deploy tokens and CI job tokens. All of them were accepted through the custom http headers.

🎇 The unwanted side impact

In Add ci job token support to the Composer packag... (!127300 - merged), a community effort was made to bring CI job token support to (2.) pulling packages. We spotted a way to do so by accepting ci job tokens sent by basic auth. Meaning that users could use the ci job token to set up the configuration of $ composer and then simply $ composer update to pull packages.

The problem is that this MR switched CI job token authentication to basic auth to all endpoints, including the register package endpoint (1.).

That unwanted side effect introduced a breaking change typebug: users with CI jobs publishing composer packages could be executed successfully anymore. 💥

The possible workaround here is to call the register package endpoint using basic auth instead of custom http headers but that is not great because it is still a breaking change.

Thus this MR will revert the auth changes for the ci job token on the register package endpoint to go back to the original behavior. This is issue CI job tokens can't register composer packages (#426617 - closed)

🔬 What does this MR do and why?

• Revert the authentication change on the composer register package endpoint: the ci job token is expected to be passed using custom http headers and not basic auth.
• Update the related specs.

This is a revert of some changes done in !127300 (merged).

🖼 Screenshots or screen recordings

None

🛠 How to set up and validate locally

There is a bit of a setup. Have a GitLab instance running with a runner.

1. Create a group and a project in that group.
2. In the project, create a composer.json file:

   {
     "name": "<group path>/test",
     "description": "Library XY",
     "type": "library",
     "license": "GPL-3.0-only",
     "authors": [
       {
         "name": "John Doe",
         "email": "john@example.com"
       }
     ],
     "require": {}
   }

3. Commit the changes.
4. Create a tag named 1.2.4.
5. Create a .gitlab-ci.yml file:

   image: curlimages/curl
   register-package:
     script:
       - 'curl --header "Job-Token: $CI_JOB_TOKEN" --data tag=1.2.4 "${CI_API_V4_URL}/projects/$CI_PROJECT_ID/packages/composer"'

6. Commit the changes and watch the runner execute the job.

On master, the runner will fail to run the $ curl command. 💥

With this MR, the runner will succeed and you can see the created package in http://gdk.test:8000/<project full path>/-/packages. ✅

🏁 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.