fix(migrations): use dweb.link instead of ipfs.io

[lidel]

This is a quick fix which replaces ipfs.io with dweb.link to allow users who's ISP is blocking ipfs.io gateway (like COX.NET here) to still benefit from HTTPS mirror.

I've confirmed this works (v0.18.0→v0.22.0), because golang's http client follows redirect to subdomain gateway:

Run migrations now? [y/N] y
[...]
Downloading migration: fs-repo-13-to-14...
Fetching with HTTP: "https://dweb.link/ipfs/QmYerugGRCZWA8yQMKDsd9daEVXUR3C5nuw3VXuX1mggHa/fs-repo-13-to-14/versions"
Fetching with HTTP: "https://dweb.link/ipfs/QmYerugGRCZWA8yQMKDsd9daEVXUR3C5nuw3VXuX1mggHa/fs-repo-13-to-14/v1.0.0/fs-repo-13-to-14_v1.0.0_linux-amd64.tar.gz"
Downloaded and unpacked migration: /tmp/migrations2100767190/fs-repo-13-to-14 (v1.0.0)

(Long term we want to have multiple names once #9159 is implemented, but for now this is an easy 1-line fix)

cc https://github.com/protocol/bifrost-infra/issues/2765 (internal ipfs.io notes)

[SgtPooki]

should we have multiple fallbacks though? and what's the reason we're not defaulting to IPFS first?

[SgtPooki]

LGTM but I would love for us to be using ipfs.io AND dweb.link. I understand there seems to be more context behind why we're not doing so now.

[lidel]

@SgtPooki yes, once we have #9159 we will implement a list that will include multiple hostnames to try.