Update the npm package validator

🍬 Context

The npm package registry has a restriction on duplicated packages:

You cannot publish a package if a package of the same name and version already exists

We're going to change what happens with this restriction when packages that follow the naming convention. Basically, those are npm packages where the scope is exactly to root namespace path. For project gitlab-org/foo/bar/test/bananas, package @gitlab-org/fruits is following the convention.

When such package is uploaded, the backend has to find out if a duplicated package exists within the root namespace. For that, it will use this function. Can you spot the issue? 😸

The duplicate existence check is done with the package name but not the package version. This means that if we have 2 projects like gitlab-org/project1 and gitlab-org/project2 and in project1, we have the npm package @gitlab-org/fruits, version 1.2.3, we can't upload @gitlab-org/fruits version 1.2.4 to project2. That upload will fail with a 400 Bad request response. This is what is described in this issue.

This existence check is before my time, so I'm not sure what happened here but reading this comment makes me think that this is from early versions of the npm package registry where the project full path was required to be in the package name.

🔨 What does this MR do?

• Update the Project#package_already_taken? function to take the package version into account.
• Update the related specs
• Update the npm API specs
• Update documentation for the npm registry so that the duplicate restriction is crystal clear on what will be checked by the backend.

🖥 Screenshots or Screencasts (strongly suggested)

Given a project @root/project1 with an npm package named @root/yay, version 1.2.3:

Project.find(34)
=> #<Project id:34 root/project1>>

Project.find(34).packages.npm
=> [#<Packages::Package:0x00007f833eeab9d8 id: 203, project_id: 34, created_at: Tue, 10 Aug 2021 07:25:27.330713000 UTC +00:00, updated_at: Tue, 10 Aug 2021 07:25:27.330713000 UTC +00:00, name: "@root/yay", version: "1.2.3", package_type: "npm", creator_id: 1, status: "default">]

We can publish @root/yay, version 1.2.4 to @root/project2:

Project.find(35)
=> #<Project id:35 root/project2>>

$ cat .npmrc 
//gdk.test:8000/api/v4/projects/35/packages/npm/:_authToken=XXXXX

$ npm publish
npm notice 
npm notice 📦  @root/yay@1.2.4
npm notice === Tarball Contents === 
npm notice 386B package.json
npm notice === Tarball Details === 
npm notice name:          @root/yay                               
npm notice version:       1.2.4                                   
npm notice package size:  352 B                                   
npm notice unpacked size: 386 B                                   
npm notice shasum:        711c2f183b682ba52e1535a64780bcaf6267ec8a
npm notice integrity:     sha512-9sY+9X+v2cA5s[...]9snD1KYBPa1ig==
npm notice total files:   1                                       
npm notice 
+ @root/yay@1.2.4

Success! 🚀

🛁 How to setup and validate locally (strongly suggested)

1. Create a group (public or private, it doesn't matter). Note the path. (path example: fruits)
2. Create a project in that group with whatever visibility and whatever name. Note the id. (example: Project1)
3. Create a second project in that group with whatever visibility and whatever name. Note the id. (example: Project2)
4. Have a personal access token ready with the api scope.
5. We're going to install a small util project that will manage npm commands for us: checkout https://gitlab.com/10io/gl_pru.
6. cd into gl_pru

Let's upload a package named @fruits/bananas, 1.2.3 to project1:

$ bundle exec thor package:push --package-type=npm --user=<username> --token="<pat token>" --url=http://<base url of gitlab>/api/v4/projects/<first project id>/packages/npm/ --name=bananas --version=1.2.3 --npm-package-scope=@fruits

The upload succeeds, you have something like:

+ @fruits/bananas@1.2.3

Now, let's upload a package named @fruits/bananas, 1.2.4 to project2:

$ bundle exec thor package:push --package-type=npm --user=<username> --token="<pat token>" --url=http://<base url of gitlab>/api/v4/projects/<second project id>/packages/npm/ --name=bananas --version=1.2.4 --npm-package-scope=@fruits

On master, this upload gets rejected with 400 Bad Request.

With this MR, the upload gets accepted with + @fruits/bananas@1.2.4

📏 Does this MR meet the acceptance criteria?

Conformity

• I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• [-] I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• [-] I have tested this MR in all supported browsers, or it's not needed.
• [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

💽 Database review

Updated query: !67427 (comment 647203652)