Add support for WASI P3

[fibonacci1729]

Moves the contents of the prototype repo into the sdk.

The additions are factored into 3 new crates:

• spin-wasip3-http-macro
• spin-wasip3-http
• wasip3-http-ext (to be upstreamed) UPSTREAMED

The contents of these repo are accessible via the spin_sdk through the http_wasip3 module.

Draft for now while I make a final pass to eliminate low hanging TODOs. Nevertheless requesting reviews now.

[fibonacci1729]

cc/ @alexcrichton @tschneidereit for comments on the general shape of the upstreamable bits and possible next steps on where this could live.

[itowlson]

I don't feel able to comment on the implementation, although what I saw looked very cool - the same kind of "wow this is going to be super convenient" as some of Ryan's early work on the Spin HTTP SDK.

I had some surface level nits and suggestions but in terms of the overall stuff it looks great to me but definitely needs other eyes on it.

[lann]

Do we want to more-explicitly frame this initial implementation as experimental/unstable (feature flag, unstable in the module name, ...)? I wouldn't necessarily want to commit to this specific RC, especially given a certain pending change. 🙂

[fibonacci1729]

This commit eliminates the http_body_util dependency in the wasip3_http_ext crate .

[fibonacci1729]

Once bytecodealliance/wasi-rs#126 lands I'll remove the wasip3-http-ext crate here.

[rylev]

Is http_component the right name? http_handler?

[fibonacci1729]

As the person who introduced http_component way back in the day, I've never loved it. Im not opposed to making this switch but I do have FUD around deviating from the norm and consistency with other sdk exports (e.g. redis, cron, mqtt, etc.).

I'd be curious to hear @itowlson's thoughts here from a dx/docs perspective.

[lann]

Or http_service? That would align with this change: https://github.com/WebAssembly/wasi-http/pull/199/files#diff-c19998709cb0805383d4515d869bb18abfe6b0758e186e28acec6fa8a11ab217

[lann]

...and would also lead the way toward a #[http_middleware] macro. 🙂

[fibonacci1729]

Oh yeah. That would be my vote.

[itowlson]

If we switch to service or handler or whatever, I'd consider retaining component (even in P3) as a transitional thing - prevalence in existing docs/blog posts, other trigger types, etc. And I am wary of rushing this decision in the last few days/hours before 3.5. But yeah I love http_component about as much as Brian does.

I'm not sure why middleware needs a different signature with a MiddlewareThingWrappingImportHandler. Why would the component not just call the global next() (or handle() or however the SDK surfaces the import) function in the way we normally do for host functions? To me it feels awkward for this one thing, one amongst all our other globals, to be injected. Or is your ... in the signature meant to imply that other things will be injected too? Anyway not an issue for now.

[lann]

I'm not sure why middleware needs a different signature with a MiddlewareThingWrappingImportHandler.

It doesn't, but my (piping hot) take is that we should pretend like it does because otherwise middleware signatures will look exactly like plain old service signatures and that seems more confusing.

[lann]

Actually we'd probably really like to not even generate the bindings for this handler import outside of #[http_middleware]. A "fake" argument seems to me like it could be the least-bad way to present that.

[fibonacci1729]

I think we should let this simmer until tomorrow to let EU folks pipe up so i'll plan to merge this PR tomorrow afternoon.

My vote would be to rename to #[http_service] because this entrypoint feels more analogous to a tower_service::Service than to what Axum refers to as a "handler". BUT whatever the people want.

I suppose to @itowlson's transitioning point, I could add:

pub use spin_wasip3_http_macro::{
        http_service, 
        http_service as http_component,
};

... to where we export all the things in lib.rs

[fibonacci1729]

I'm going to go ahead and make the change to #[http_service]. However, this PR will remain open until Monday to leave an opportunity to object!

[itowlson]

LGTM. I imagine we're going to need some iteration as we gain more experience with it so I like putting it under a feature guard while we and others kick the tyres on it!