Packagist API performance, composer v2 fixes

[chillu]

5c87deb (Ingo Schommer, 17 seconds ago) FIX Logic flaw in README building

This only works if the first candidate is matched, since it returns rather than breaks the loop.

9ba9689 (Ingo Schommer, 53 seconds ago) FIX Composer v2 compat, requires install

Previously it was enough to download() a package, which would actually write files into the provided $targetDir. The method still claims to do that, but for the GitDownloader it uses a separate global composer cache instead and doesn't touch $targetDir. You need to call install() to actually write to the path.

Weirdly, this seems different from a "composer install", it only copies the files, and doesn't create a vendor/ folder. Which is desireable in our case, since we don't want the builder to be slowed down by checking out more files we don't need.

c12c130 (Ingo Schommer, 4 minutes ago) NEW Packagist API performance

Hopefully avoids us getting rate limited. Uses statically cached files with less metadata, so we need to shift some of the addon data population from the updater to the builder. This doesn't reduce the number of API calls overall, but it makes most of them a lot "cheaper" for Packagist.

See https://packagist.org/apidoc:

Using composer metadata: This is the preferred way to access the data as it is always up to date, and dumped to static files so it is very efficient on our end.

The UI is already set up to deal with partially populated packages

[chillu]

Thanks for reviewing!

@chillu Do you think we'll be able to drop the fork out before shipping or should we proceed as-is for now?

I've set myself a reminder to check in with the maintainers on the pull request in two weeks. Doesn't block shipping IMHO.

I've added a few more commits to the PR since your review, but they're all pretty minor. Up to you if you want to review them separately!