Allow changing socket blocking state

[WhySoBad]

Hi,

This pull request adds the required functionality to change the network socket blocking state through ioctl (used by the standard library) and fcntl.

Since the ioctl shim now allows changing the socket blocking state through the standard library, there are now also some tests for testing non-blocking sockets using the standard library. However, we cannot test non-blocking connects this way, as we would need mio for that.

Is it worth adding mio as a test dependency for this in a future PR? Because we already test non-blocking connects using libc.

Also, because setting the blocking state of a socket through fcntl is supported on all targets, we can now also run the libc non-blocking socket tests on MacOS targets.

[rustbot]

Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

[RalfJung]

Thanks! :) Just a bunch of fairly minor comments.

@rustbot author

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[WhySoBad]

@rustbot ready

[RalfJung]

This looks great, thanks! After resolving the last comment nit, please squash the commits. You can squash manually if there are multiple independent commits you want to preserve, or use ./miri squash (make sure to pick a suitable commit message). Then write @rustbot ready after you force-pushed the squashed PR.

@rustbot author

[WhySoBad]

@rustbot ready

[WhySoBad]

@RalfJung some test failed on the CI on the PR on my branch, can you still remove it from the merge queue?

[WhySoBad]

I think this is a timing issue. Probably, the socket is still connecting when we're calling recv. If that's the case, we also need to loop there, but this time when ENOTCONN is returned:
https://github.com/WhySoBad/miri/actions/runs/24403117527/job/71278916255

[WhySoBad]

If that's the case, we also need to loop there, but this time when ENOTCONN is returned

I've now added a new test, which only tests non-blocking connect and awaits the connection using such a loop. Everywhere else I changed the tests to connect whilst the client socket is blocking and only afterwards set the socket to be non-blocking.

[RalfJung]

👍 please re-squash. (You can do this preemptively for such tiny fixes if you want.)