feat(hex): use registry v2 for packages rather than hex.pm http API

[bryannaegele]

Changes

• use hex registry v2 for package information
• use hex.pm package API for supplemental package metadata when package is hosted there.
• support registryAliases for private repo/registry mapping
• run mix.repo add in mix manager for private repos

Context

#29622

This changes the hex datasource to use hex registry v2 for package management. Hex registries are not required to implement an http API like hex.pm has, so the prior implementation prevented updating of packages in private repos such as oban pro. Additionally, due to the way mix works when updating dependencies, mix.lock files could not be updated when such a dependency existed and the mix manager ran mix deps.update <<updated packages>>.

In order to keep as much parity with the prior implementation, hex.pm is used for supplemental package metadata where possible.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[bryannaegele]

Leaving this as a draft until there's an answer for this #29622 (comment)

I am no TS expert, so please feel free to jump in and fix up whatever can be done better.

[viceice]

reduce fixtures, we don't need all versions for testing, ~3 are enough. ensure the tgz file is at minimum too

[viceice]

use async functions

[viceice]

this should be generated on build and not checked into git. or fix it to a readable format for proper linting.

[bryannaegele]

Can you help with how you would go about that? I am not a TS developer and this is what was generated by https://www.npmjs.com/package/ts-proto#usage, unedited in any way. There are a lot of options that can be passed to it but it's all foreign to me. The comment and eslint ignore are output by ts-proto.

I'm not sure how generating the files on build ends up with a different result. It would still be the same code, just lint ignored? And the code has to be there for unit tests, so I'm not clear on how a build step improves things.

[viceice]

you need to add that package to dev dependencies, then add a generate step to package.json scripts. there are already some generation steps as samples.

[bryannaegele]

reduce fixtures, we don't need all versions for testing, ~3 are enough. ensure the tgz file is at minimum too

Is this strictly necessary? The tgz has the registry version of the package wrapped in a signed wrapper. I don't have any way to create a version with less releases in it that would have a valid signature.

I can try to find a different package as an example but this is one of the rare ones with retirements.

[bryannaegele]

Mix changes split to #29775