Use rustix instead of libc

[notgull]

Closes #847

rustix is a wrapper around either raw Linux system calls or libc, based
on the current platform. The main advantage is that it can make programs
much more efficient, since system calls can be inlined directly into
the functions that call them. I've seen rustix reduce instruction counts
in my programs when I've made the switch in another programs.

In addition, it reduces the amount of unsafe code.

[joshka]

Would it make sense to implement this as an alternative behind a feature flag rather than a direct replacement? Doing this would make it more convenient to compare any performance differences and behavior changes.

[notgull]

Would it make sense to implement this as an alternative behind a feature flag rather than a direct replacement? Doing this would make it more convenient to compare any performance differences and behavior changes.

I don't think so. The question comes down to how we expose this as a feature flag.

• Do we make libc the default and expose rustix as an optional feature? Then rustix users will still be lugging around a libc dependency that they might want to get rid of. And vice versa, for rustix being the default and libc being an optional feature.
• If we make them both optional and require the end user to enable them, this starts up endless bickering about feature unification and enabling them in the dependency tree. For instance, if crate a enables the libc feature and crate b enables the rustix feature, which one do you use?

It adds a lot more complexity than just using one backend does.

[joshka]

One approach to mutually exclusive feature flags like this is to use cfg(not(feature(...)) (or cfg_if). I'd imagine that we'd only need a libc feature.

My context on this is as a maintainer of Ratatui, where we generally suggest people choose Crossterm as their backend. I'd like to get a feel for whether this change has actual performance benefits, and I'm sure that being able to measure that would be nice.

Doing things with alternative implementations instead of pure replacement also carries less inherent risk - especially when there's no tests.