Prioritize download from ghcr manifest

[Azathothas]

Earlier today, Cloudflare disabled access to our buckets and workers.
This was done in an attempt to make us switch to their enterprise plan because apparently our paid plan isn't enough to handle recent spikes.
We still have limited access such as we can still access features like dns, redirects etc.
I have pushed a fix to rewrite urls for the metadata, so it doesn't break soar core.

What will be broken (We got downgraded to free plan, so 100k reqs) however are these (fields from the metadata):

• appstream
• build_log
• desktop
• download_url
• icon
• manifest_url
  anything else that uses pkgforge.dev domain except for:
• the metadata (Fixed with url redirects)
• pkg_webpage (Uses Github pages)

How can this be fixed:

• Switching to ghcr for everything, as we already have a similar plan in: Add a way to install only main binary/package (Needed files) #23

[pkgforge-bot]

🤖 Automated Response
Thanks for opening this issue!
Quick Details:

• 📋 We'll review it shortly
• 🕒 Typical response time is 12-24 hours
  Want faster resolution or more community support?
  Join Our Discord: https://discord.gg/djJUs48Zbu
  Connect directly with our team, get quicker responses, and engage with our community!

[QaidVoid]

Looks like not much to do here. These fields are mostly fallbacks in case the required files weren't downloaded alongside GHCR package.
Even then, these URLs should be fixed in the metadata itself..

[Azathothas]

Even then, these URLs should be fixed in the metadata itself..

As in, replace these with blob sha?

[QaidVoid]

I mean, use the official ghcr URLs.
Which probably means using blob sha? Then, yes.

[Azathothas]

I mean, use the official ghcr URLs. Which probably means using blob sha? Then, yes.

They were added so it could be used from the browser.
Otherwise no need since the manifest will already contain everything.

I had like to keep our options open, in case Cloudflare gets restored or another alternatives is discovered.
Soar should simply ignore them if the ghcr_pkg field is present in the metadata.
Nests, where the api (because it is ours) won't be present, these fields will probably be absent.

[Azathothas]

For external repos and anything that doesn't have ghcr_* fields, it's fine to use build_log

For instance:

• soar log jq#github.com.jqlang.jq.source:bincache works
• soar log 0ad#AM.x86_64.0ad.0ad:ivan-hc-am doesn't work