fix: don't fail exceptfds with ENOSYS, just zero them'

[kilyanni]

pselect returned ENOSYS whenever errorfds held any descriptors, since wasix poll_oneoff has no exceptional-condition (POLLPRI) event type.
This breaks the common idiom of passing all three fd sets defensively and treating only EBADF as fatal (e.g. rsync, whose select loop spins on the ENOSYS).

Exceptional conditions are unobservable on wasix anyway, so report that no descriptor is exceptional (FD_ZERO(errorfds)) and proceed on read/write instead of failing the call. Also fixes select(), which forwards to pselect().

[kilyanni]

Conclusion: try implementing this properly via a new syscall that does report errors

[Arshia001]

This introduces a potential deviation from applications' expectations, where an app that actually depends on checking for errors through select will just never see any errors and assume everything is going well. The proper fix would be to introduce proper support for reporting errors through select, which probably requires a new syscall.

[kilyanni]

Thinking about it for a bit, I now think this is actually the right approach.

exceptfds does not actually report errors, it reports exceptional data, aka POLLPRI, which we globally define to be equal to POLLIN. So this is not really something this codebase is set up for. It is also incredibly niche to be using POLLPRI nowadays.

There are some edge cases in Linux where exceptional condtions may occur (procfs, sysfs, cgroup stuff) all of which don't exist inside wasix. The only real case would be TCP OOB which is generally discouraged, and we do not produce it anywhere at the moment.

TL;DR: this is not fully correct, but it breaks way fewer consumers than the status quo. Full OOB handling could be done in a follow up but does not unblock any consumer I know of, so low prio

[kilyanni]

nevermind, implementing TCP OOB is quite reasonably doable, gonna do that