Introduce WAPM query caching to reduce wasmer run's startup delay

[Michael-F-Bryan]

We've discovered that there is a ~1 second delay on startup when running something like wasmer run python/python. After some investigation with @dynamite-bud, we narrowed it down to a GraphQL query which will be executed every single time we try to fetch metadata from something that looks like a WAPM package.

wasmer/lib/wasix/src/runtime/resolver/wapm_source.rs

Lines 53 to 78 in f93f083

	tracing::trace!(%body, "Sending GraphQL query");
	let request = HttpRequest {
	url: self.registry_endpoint.clone(),
	method: Method::POST,
	body: Some(body.into_bytes()),
	headers: headers(),
	options: Default::default(),
	};
	let response = self.client.request(request).await?;
	if !response.is_ok() {
	let url = &self.registry_endpoint;
	let status = response.status;
	anyhow::bail!("\"{url}\" replied with {status}");
	}
	let body = response.body.unwrap_or_default();
	tracing::trace!(
	body=?String::from_utf8_lossy(&body),
	"Received a response from GraphQL",
	);
	let response: WapmWebQuery =
	serde_json::from_slice(&body).context("Unable to deserialize the response")?;

The simplest way to solve this is by caching the response from this sort of GraphQL query, marking the cached value as stale if it's older than (for example) 10 minutes or we've just run wasmer publish. It'd be nice if we could use a sqlite database for the cache, but I'm not sure how that'd go on the web.

Fixes #3962

[Michael-F-Bryan]

I've added a filesystem cache in front of WapmSource. Now it'll cache the response of a GraphQL query to $WASMER_DIR/queries/ as a JSON file (e.g. looking up the available versions for python/python would save to $WASMER_DIR/queries/python/python).

With this system, a cache miss from Australia takes about 800ms to query the WAPM backend (time.busy=19.2ms time.idle=765ms) and a cache hit takes less than a millisecond (time.busy=689µs time.idle=11.4µs).

[theduke]

Once concern here: wasmer publish xxx, wasmer run xxx will run the old version.

Should we purge the cache for a package when publish is run?

I know this kind of inter-mingled logic is suboptimal, but I think it's an annoying UX gotcha otherwise.