Tracking issue for WASIp3

[adamrk]

Plan

The ultimate goal is to have wstd use WASIp2 when compiled to wasm32-wasip2 and WASIp3 when compiling to wasm32-wasip3, with essentially the same APIs.

Until rust-lang/rust#161940 has landed we'll create mutually exclusive p2 and p3 features on wstd, where p2 will be enabled by default and p3 will only be run in CI during development, not meant for actual use. Then we can switch the feature directives to target_env directives when the work is complete and wasm32-wasip3 is tier 2.

Breaking Changes

• The stream APIs in io and TCP APIs in net work with & references and will switch to requiring &mut. This is because p2 is a single threaded environment, whereas p3 is not. This change will be made to both targets to keep them in sync.
• Some APIs expose the underlying WASIp2 types (e.g. AsyncInputStream::new takes a wasip2::InputStream) these will naturally change to use the equivalent WASIp3 types. This will only be breaking when upgrading to the WASIp3 target.
• (Up for discussion) The wasip3 crate has its own Task type which wstd could use directly instead of async_task::Task. If done this would be another breaking change between the two targets.

Checklist

• Create p2 and p3 features #144
• Make & -> &mut breaking API changes required for WASIp3 #145
• Create main macro for WASIp3 #148
• Implement runtime on WASIp3
• Implement rand on WASIp3
• Implement time on WASIp3
• Implement io on WASIp3
• Implement net on WASIp3
• Implement http on WASIp3
• Implement wstd-axum on WASIp3
• Remove p2/p3 features and use target_env instead #147
• (Optional) Switch from async_task::Task to wasip3::Task

[yoshuawuyts]

Oh I'm just realizing we (I) never ended up merging #134. We should probably start there tbh as it covers the basics for p2.

[adamrk]

I think separating everything out like that might be a bit of overkill. From doing a sloppy implementation myself it seems like most cases can be handled with just a few inline directives within the same file (stream was the only place that really justified a completely different module). I can put up that code if you want to see it, but just be warned it's a mess...

[yoshuawuyts]

We originally tried that and rejected that approach in #127; we moved to the sys/-based approach only after that. #134 not being merged was mostly an accident, and we probably do want to take that approach.

[adamrk]

Ok, sounds good!

[pchickey]

I'm inclined to let @adamrk pick his own path with regard to whether a given site should use an inline cfg or separate things out into separate sys modules- he's built a rapid prototype and is working through the design decisions one at a time. Introducing the features isnt the interesting part here (nor really the root of why I wasn't thrilled with #127) but how we deal with all of the details after that, and #142 is a 130 line diff whereas #134 is a 1500 line diff, so lets start with 10% the complexity and if it ends up needing more later it can be applied when and where appropriate. Its a lot harder to delete unneeded complexity later than it is to avoid adding it now.

[yoshuawuyts]

@phickey hah, sounds like I'm outnumbered. If you both would like to go that direction instead, I'm happy to yield to y'all's decision making.

@adamrk by the way, thank you so much for taking this on! I'm very excited for this to progress!