Report crypto error cause along with $errno

[ueno]

Related to #6.

Rather than using own error codes for the crypto operations, this makes the functions return the cause of failure ($crypto_error_cause) along with the normal $errno. That way, the caller can handle e.g., $errno.nosys in a similar manner to the rest of WASI hostcalls.

[jedisct1]

Mmm... returning two error codes is going to be a little bit awkward to handle and may not play well with wiggle.

How would you recommend returning module-specific errors, while some of these errors may overlap with standard errors @sunfishcode ?

Maybe submodules could share the standard errno type, with values having the high bit set?

[sunfishcode]

My suggestion is to try avoiding $errno altogether for now. Staying consistent with things like ENOSYS in non-crypto APIs is lower priority than designing a good API for crypto.

A few background thoughts:

It's valuable in a crypto API to think through the possible failure modes, and how you want applications to handle them. Defining your own error codes is one way to push yourself to think this through. In the particular case of ENOSYS, think about whether what you really have is optional functionality and optional imports would be a better fit, or essential functionality, where it makes sense to just require implementations to implement it if they implement WASI-crypto at all, and maybe don't give them the option of returning ENOSYS. I'm oversimplifying, but my broader idea is just: think about what makes sense for your API first.

As a separate thought, $errno errors are mostly relevant at the scope of code which does approximately one system call. Once you zoom out to code that does multiple system calls, even something like ENOSYS becomes mostly meaningless. At the scope of code which is calling functions in both the more POSIX-style parts of WASI and WASI-crypto, a single errno-style error code won't carry relevant information. To illustrate, picture a function call that does some I/O and some crypto, and uses $errno as its return type. If you call it and it returns EINVAL or ENOSYS or most any other errno code, you can't do a lot with that information except treat it as a generic failure, because you don't know which function failed or how it failed. Consequently, I don't expect it will be important to have a single errno type which spans all WASI APIs.

[ueno]

OK, let's close this and use the $crypto_errno exclusively.