std.os: add support for socketpair

[notcancername]

fixes #18417
cc @nektro

with the AF_UNIX implementation, the file the socket is bound to is not cleaned up, it might be worth exposing this eventually or abstracting socketpair properly in std.net (related: #6600), comments are appreciated

(also: fix an error where recvfrom would use std.c instead of std.os.windows even when libc is not linked)

[nektro]

some thoughts in no particular order

• nice!
• if windows doesn't have this behavior I don't think std.os should pretend it does imo.
• additionally it should accept i32 or c_int and not bitCast
• E.OPNOTSUPP, E.PROTONOSUPPORT shouldn't be in the same case
• neither should E.NOBUFS, E.NOMEM
• there shouldn't be util functions, it should all be in the if statement of socketpair
• common style for std.os is if (windows) { _win_ } _posix_, this is in the wrong order and shouldn't use an else

[notcancername]

• if windows doesn't have this behavior I don't think std.os should pretend it does imo.

Seems like std.net is the preferred layer for this?

• E.OPNOTSUPP, E.PROTONOSUPPORT shouldn't be in the same case
• neither should E.NOBUFS, E.NOMEM

Which errors would be more appropriate?

there shouldn't be util functions, it should all be in the if statement of socketpair

They're separate functions because AF_UNIX may not be available at runtime:

        error.AddressFamilyNotSupported => return socketpairEmulatedAfInet(),

additionally it should accept i32 or c_int and not bitCast

std.c.socketpair uses c_uint, but std.os.linux.socketpair uses i32. Some amount of casting was unavoidable. I've changed std.os.linux.socketpair to fit std.os.socket precedent.

[nektro]

std.c.socketpair was wrong. they all should be using c_int/i32.

https://pubs.opengroup.org/onlinepubs/009696699/functions/socketpair.html
https://www.man7.org/linux/man-pages/man2/socketpair.2.html
https://man.freebsd.org/cgi/man.cgi?query=socketpair(2)

[nektro]

        .OPNOTSUPP => return error.OperationNotSupported,
        .PROTONOSUPPORT => return error.ProtocolNotSupported,
        .NOBUFS => return error.SystemResources,
        .NOMEM => return error.SystemResources,

[notcancername]

done. why are we using separate switch prongs for the same error?

[nektro]

no particular reason afaik. just the style that core team/prs has kept up so far in this case to keep things vertical

[notcancername]

these test failures are looking pretty mysterious:

 src/Sema.zig:32601:92: error: no field or member function named 'toValue' in 'InternPool.Index'
src/InternPool.zig:2010:19: note: enum declared here
child process failed
Aborted
Error: Process completed with exit code 134.

I don't see how my changes could possibly have caused this

[nektro]

looks like master branch is failing too

[andrewrk]

no