lib/wasi-types: add Socktype::Unused shim value

[waynr]

Description

In wasix-libc we derive the value of the C macro SOCK_DGRAM and SOCK_STREAM from the sock_type enum in wasix-witx. This sock_type witx enum corresponds roughly to the Wasmer socktype enum.

The problem with these corresponding enums as-written is that they result in a SOCK_DGRAM value of 0. This doesn't work for cpython (and potentially other programs depending on libc) because the value 0 is used for a cpython-specific macro that is used in a switch case arm alongside SOCK_DGRAM:

• cpython's GAI_ANY macro defined as 0
• cpython's GAI_ANY used next to SOCK_DGRAM in a switch block

This cpython hack seems likely to me to be replicated elsewhere in the open source world and implies that most libc implementations likely don't have any SOCK_* macros with the value 0.

This PR is paired with a corresponding wasix-witx PR. Both PRs utilize the same hack: introduce a shim enum variant to ensure that none of the other variants take the value 0.

[theduke]

This will break all wasix code we have compiled that uses sockets.

I do think it makes sense to have this instead of doing the mapping in libc, because that creates confusing ambiguities, but we'll need to change the wasix crate and the libc in unison with this PR.

And then re-compile everything using sockets, including the snapshot tests.

Thoughts, @john-sharratt ?

[waynr]

This will break all wasix code we have compiled that uses sockets.

I do think it makes sense to have this instead of doing the mapping in libc, because that creates confusing ambiguities, but we'll need to change the wasix crate and the libc in unison with this PR.

And then re-compile everything using sockets, including the snapshot tests.

Thoughts, @john-sharratt ?

John and I discussed this last night and came to the same conclusion as you, but we decided we would wait to merge it until we are reasonably certain no more breaking changes are needed for what I'm working on.

[theduke]

This was included in #3906 .