Update package-lock.json parsing strategy

[eleftherias]

• Start by finding any version changes
• Then find the package name whose version was changed

Fix #1631

[jhrozek]

This is a clear and nice improvement thank you.

While reading the PR I was wondering if the approach that I took with the original code where we parse the patch is just too fragile though and we'd find even more issues later. What if we did the following instead (later of course):

• grab the whole file that was patched and parse all dependencies to get a slice of pb.Dependency
• grab the original and parse it, too
• see which dependencies changed
• find them in the patch to get context
• use that instead to add reviews at the right places

The reason I started thinking about this was really this test case:

+   },
+    "node_modules/undici-types": {
+      "version": "5.26.5",
+      "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz",
+      "integrity": "sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA=="

and the fact that package-lock.json might be just so easy to parse otherwise and I bet there's also libraries we could use.

[eleftherias]

This is a clear and nice improvement thank you.

While reading the PR I was wondering if the approach that I took with the original code where we parse the patch is just too fragile though and we'd find even more issues later. What if we did the following instead (later of course):

• grab the whole file that was patched and parse all dependencies to get a slice of pb.Dependency
• grab the original and parse it, too
• see which dependencies changed
• find them in the patch to get context
• use that instead to add reviews at the right places

The reason I started thinking about this was really this test case:

+   },
+    "node_modules/undici-types": {
+      "version": "5.26.5",
+      "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz",
+      "integrity": "sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA=="

and the fact that package-lock.json might be just so easy to parse otherwise and I bet there's also libraries we could use.

@jhrozek I agree that's a cleaner way to do it. We might need to rethink how we define the rule, because if we're getting the whole file instead of the patch we need something other than the diff ingester.