Initial interface

[badeend]

Aside from the boilerplate, this adds types.wit.

This should be the bare minimum interface to set up client TLS connections within a WASI guest.

Compared to the PR over at the wasi-sockets repo, this PR:

• has merged the client-connection::constructor and client-connection::connect methods into the client-handshake::constructor, and
• the client-connection is now returned asynchronously by the client-handshake::finish method.

This decreases the API surface area and removes a chance of user-error thanks to the introduced typestate.

The general process now looks like:

• Call client-handshake::constructor
• Configure handshake to your liking. In this PR there's nothing to configure yet.
• Call and await client-handshake::finish
• Use returned IO streams and client-connection as usual.

---

Next steps, for future PRs:

• Add documentation
• Add proper error handling

[dicej]

LGTM, thanks!

[dicej]

I imagine we'll want to define a variant error type with cases covering at least the most common failure cases (e.g. expired certificate, hostname mismatch, etc.) and use it here, eventually.

[badeend]

Yup, definitely. 👍

I wasn't in the mood to do a full inventory of all the ways a TLS connection may fail just yet, so I lazily wrote it off as a problem for future me 😅

[jsturtevant]

one thing we will need eventually for dotnet is the server-identity: func() -> option<public-identity>;. After accepting the connection dotnet SSL client runs through a second round of server certificate validation.

[jsturtevant]

Another thing that we are using the .net implementation is the make-pipe: func() -> tuple<input-stream, output-stream>;

Should that live here or wasi:io/streams? This will go away as we look towards wasi 0.3?

[jsturtevant]

LGTM

[badeend]

@jsturtevant Replying to your server-identity & make-pipe dependency simultaneously: for the purposes of this PR, they seem to be purely additive to the initial interface, so I'm going to merge this one. I'd be glad to continue discussing the needs of .NET outside of this PR. Hit me up on Zulip, a video call, a Github issue, or however you want.

Should that live here or wasi:io/streams?

Ideally we shouldn't need this at all. Second choice: add it to wasi-io. But lets discuss further.

This will go away as we look towards wasi 0.3?

Yes, this is v0.2-only.