Add WASIp3 support

[dicej]

This adds wasi:{cli,clocks,filesystem,http,random,sockets}@0.3.0-rc-2025-09-16 support, including inbound and outbound HTTP requests.

I've smoke tested this manually with a few WASIp3 components and plan to port over some or all of the existing WASIp2 tests.

Note that this builds on #3271

TODO:

• Port (some) wasi:[email protected] tests
• Add Instrument::in_current_span calls where necessary (e.g. in wasip3.rs)
• Update to next release candidate once the release-37.0.0 branch supports it
• Switch to the final 37.0.0 release once it's available

[alexcrichton]

Looks good to me on all the Wasmtime bits, thanks! I'll defer to others for the Spin-related bits though.

[dicej]

I'm not able to repro the CI error on Mac or Linux. I tried rerunning the job, but it failed the second time. Not sure what's up. UPDATE: fixed

[itowlson]

Not sure my approval is worth much but here it is anyway! Great to see this, excited to give it a try!

[itowlson]

Do we know the status of this TODO?

[dicej]

Good question. It's also ignored in wasmtime-wasi, and it seems redundant to me. I assume it represents an error reading the request body, but that should be reported via the BoxBody<Bytes, ErrorCode> in the request; no need for a separate parameter. I'll ask Roman (who wrote that code) about it. Nevermind; see my comment below.

[dicej]

Oops, I should have read the docs more carefully. That future may be used to learn about errors the guest might encounter while doing whatever it decides to do with the response we return here. Arguably we don't care, though -- we've done our job producing the response, and we can't do anything about it here if the guest has trouble e.g. forwarding it elsewhere. I'll update the comment to say so.

[itowlson]

I don't quite understand, but probably don't need to, except to ask: would that include guest errors produced after the response has been finished? (The reason I ask is e.g. the Slack bot scenario, where the bulk of the work may happen after the ack response has been returned: current Spin can be a bit weird about errors in that phase if I remember rightly.)

(I realise "a bit weird about" is, uh, a bit vague, but I have forgotten the details.)

[itowlson]

Never mind, I'm an idiot: this is outbound HTTP. Sorry for the noise.

[dicej]

would that include guest errors produced after the response has been finished?

The guest can send an error to fut at any time, i.e. before, during, or after the response has arrived in full and been delivered to the guest; there's nothing in the API that constraints when or why the guest would do that. In any case, there's not much we can do about it here 🤷 .

[lann]

Just FYI

Suggested change

	let Ok(name) = n.parse::<HeaderName>() else {
	return None;
	};
	let Ok(value) = HeaderValue::from_bytes(v.as_bytes()) else {
	return None;
	};
	let name = n.parse::<HeaderName>().ok()?;
	let value = HeaderValue::from_bytes(v.as_bytes()).ok()?;