Fixed an issue where the package loader was blocking the tokio runtime

[john-sharratt]

No description provided.

[Michael-F-Bryan]

One thing we'll need to be careful of is to only ever use the BuiltinPackageLoader within a tokio context, otherwise we'll have "tried to use tokio outside of a runtime context" panics.

That was already a problem as of 7885976 (from #4204) when we originally introduced the tokio::task::block_in_place() calls though and we haven't seen panics in the last couple months, so maybe it'll be fine.

<rant>

The PR as it currently stands is fine and should mitigate some of the stability issues we were seeing on Edge, however it reiterates some concerns I have about the the way our wasmer_wasix::Runtime is structured and how we have dependencies between components.

As an example, the BuiltinPackageLoader requires access to a VirtualTaskManager because it needs to run blocking code. We are currently using tokio::task::spawn_blocking() which implicitly assumes the BuiltinPackageLoader will be used inside a tokio context.

A "cleaner" approach would be to either refactor BuiltinPackageLoader to accept an Arc<dyn VirtualTaskManager> in its constructor, but then it gets harder to create and a given BuiltinPackageLoader instance will always be coupled to that VirtualTaskManager instance.

We have similar coupling in other places which require things like a HTTP client. The BuiltinPackageLoader already depends on a HTTP client, but it's also used for things like the dependency resolver.

If we have have cross-component coupling like this anyway, we may as well make it explicit by passing the dependency in when they are used. For example:

#[async_trait::async_trait]
pub trait PackageLoader: Send + Sync + Debug {
    async fn load(&self, summary: &PackageSummary, http_client: &Arc<dyn HttpClient>) -> Result<Container, Error>;
}

(or instead of passing the HTTP client directly, we could pass in a &dyn Runtime or some &dyn PackageLoaderContext helper trait or whatever)

Hiding these cross-component dependencies like we have been so far doesn't make things cleaner. It actually makes the code harder to use because you need to instantiate components in a specific order and if you want to change one component out you need to recreate any components that depends on it. That's had a tangible effect on the WasmerJS public API because it means people can't do "obvious" things like updating the HTTP client after the runtime has already been instantiated (e.g. to add auth when using private packages).

</rant>

[syrusakbary]

We probably want to pass a tokio handle to prevent cases where we call this without tokio running under the hood