Expose handshake error

[badeend]

This updates client-handshake/get to return a wasi:io/error on failure.

There are two sources for errors during the handshake:

• The underlying transport; the stream pair passed into the client-handshake constructor produced an error. In that case, the handshake object passes that error on to the consumer as-is. E.g. assuming the TLS stream wraps an TCP stream, it is possible to call wasi:sockets/network/network-error-code on an IO error returned from the TLS handshake.
• The TLS implementation itself. E.g. certificate expired, TLS version mismatch, etc. For now, the message accessible through wasi:io/error/to-debug-string is the only way for a guest to know what went wrong. We could add a tls-error-code method in the future similar to wasi-sockets, wasi-filesystem & wasi-http if the need ever arises to downcast into a structured variant.

Relates to:

• Tracking issues for CI spurious network failures with example.com bytecodealliance/wasmtime#10369
• future-client-streams/get returns no error code #9

[jsturtevant]

should we be returning some type of error information for the first result here?

related to bytecodealliance/wasmtime#10429 (review)

[badeend]

This funky signature has been lifted from wasi-http:

https://github.com/WebAssembly/wasi-http/blob/main/wit/types.wit#L671-L686

    /// The outer `option` represents future readiness. Users can wait on this
    /// `option` to become `some` using the `subscribe` method.
    ///
    /// The outer `result` is used to retrieve the response or error at most
    /// once. It will be success on the first call in which the outer option
    /// is `some`, and error on subsequent calls.
    ///
    /// The inner `result` represents that either the incoming HTTP Response
    /// status and headers have received successfully, or that an error
    /// occurred. 

• The outer result is there to signal that the inner result has already been consumed by a prior call.
• The inner result is the actual result type of the future.

[jsturtevant]

got it thanks!

[jsturtevant]

• The TLS implementation itself. E.g. certificate expired, TLS version mismatch, etc. For now, the message accessible through wasi:io/error/to-debug-string is the only way for a guest to know what went wrong. We could add a tls-error-code method in the future similar to wasi-sockets, wasi-filesystem & wasi-http if the need ever arises to downcast into a structured variant.

this makes sense to me for now, as we receive usage and feedback we can adjust if the users need more detailed error processing