Handle parsing a PackageId that is a raw registry url into a Crate

[Skgland]

I noticed that a lot of errors that I would expect to be categorized as DependsOn(_) would end up as Unknown instead.

It looks like cargo sets the package_id field in the json output to registry+https://github.com/rust-lang/crates.io-index#{crate_name}@{crate_version} which wan't handled by Crate::try_from.
As a result no crate would be inserted into the deps set and it wasn't able to differentiate between an empty deps set due to no errors in dependencies and an empty deps set because the package_ids field of failing deps couldn't be parsed into a Crate.

[Skgland]

Looking a bit further it looks like in 1.77/1.78 cargo switched to packeg id spec.

Should I add a todo comment for implementing the parsing of the package id spec completly and cleaning up the old package id parsing? Other than that I would consider this ready for review.

[Skgland]

I have replaced the manual URL parsing code,
initially by using url::Url,
but based on a suggestion by epage rust-lang/cargo#15048 (comment) I replaced it with PackageIdSpec::parse

[pietroalbini]

I'm glad you found a package to parse the IDs :D

Left a small comment. Also, as before, I think we should not set the version to "unknown" if it's missing, but error out instead, as I don't know how the rest of Crater would handle it.

[Skgland]

I'm glad you found a package to parse the IDs :D

Left a small comment. Also, as before, I think we should not set the version to "unknown" if it's missing, but error out instead, as I don't know how the rest of Crater would handle it.

I think I missed that remark last time, I will change that then.

[Skgland]

Ok, I have rebased to resolve merge conflicts and addressed your remarks regarding turning missing version into unknown and the crate-name repo-name mixup for GitHubRepo crates.

I think how I handle the sha field for GitRepo and GitHubRepo crates needs to be changed as well.
Currently this just puts the GitReference in there whether that's a commit hash or not,
also even if it is a commit hash it currently gets a rev= prefix added to it.

[Skgland]

Tags, Branches and non-hex revs now result in sha being None.

[pietroalbini]

Thanks! ❤️

[Skgland]

minicrater failed, it looks like some classifications changed, the new classification looks to be an expected improvement and this changed result just needs to be blessed, though CIs expected to actual diff is a bit hard to read as the coloring ends on linebreak, so I will need to check this locally.

[Skgland]

Ok, I have now updated the minicrater expectations in the latest commit.