Download actor bundles at runtime

[LesnyRumcajs]

Issue summary

Background

This PR #3276 moved runtime actor downloads to compile-time. At the moment, the actor bundle sits in the git lfs (#3360). With every new actors' bundle, we need to update it (append new bundles). Until the last upgrade, the bundle size was only ~2.3MB. The NV21 bundle (which is still missing a bundle for mainnet) is almost 8 MB.

Problem

crates.io has a hard limit of 10 MB enforced during cargo publish (at the push stage, so our dry-run wouldn't catch it). With the new bundles, we exceed this limit

error: failed to publish to registry at https://crates.io/

Caused by:
  the remote server responded with an error: max upload size is: 10485760

We still want to push to crates.io.

Solution

Move downloading all-in-one bundle to runtime. Theoretically, we could do it at the build stage, but cargo publish wouldn't accept it. We should store the all-in-one bundle in:

• GH releases
• DO or CF R2 as backup if GH is down
  Use that endpoint to download the bundle at Forest startup.

Also, we have to publish unreleased forest versions (so far it's only 0.14.0).

Acceptance criteria

• All-in-one bundle is stored GH assets as part of a release
• All-in-one bundle is automatically added to the release (release workflow needs to be modified)
• All-in-one bundle is mirrored either in DO or CF R2 (preferably, automatically)
• Forest downloads the bundle at startup. If GH is down, it downloads from the mirror.
• The bundle is stored in Forest data directory. Forest must not re-download it if it was already downloaded.
• git-lfs asset is removed
• All Forest releases that weren't published on crates.io are released.

Other information and links

[LesnyRumcajs]

Instead of hosting the all-in-one bundle, I currently implemented downloading the bundles from GH (built-in-actors releases) and, alternatively, DO. The all-in-one file is not cached anywhere - it's in the DB and checked at startup that all manifests sit there.

The downside of this approach is that at startup, the user has to download significantly more (the actor bundles are not compressed). Also, in a DB cleanup, they have to re-download it.
The upside is that we have less code to manage and fewer lingering files in the data directory or some other cache.

[aatifsyed]

Theoretically, we could do it at the build stage, but cargo publish wouldn't accept it.

It's not clear to me that cargo-publish would reject this. I still don't think we should do it, but a crate is allowed to dial the web in build.rs

[aatifsyed]

Is there a way to eagerly cache the required bundles?
forest-tool cache-bundles or something?

If I'm trying to run forest before e.g not having internet, can I know I won't need it?

[LesnyRumcajs]

Is there a way to eagerly cache the required bundles? forest-tool cache-bundles or something?

If I'm trying to run forest before e.g not having internet, can I know I won't need it?

❯ forest --chain calibnet --encrypt-keystore false --exit-after-init

[LesnyRumcajs]

Done in #3622 and #3658