RFC: io and os reform

This RFC proposes a significant redesign of the `std::io` and `std::os` modules
in preparation for API stabilization. The specific problems addressed by the
redesign are given in the Problems section below, and the key ideas of the
design are given in Vision for IO.

[Rendered](https://github.com/aturon/rfcs/blob/io-os-reform/text/0000-io-os-reform.md)
> Sounds like chmod in its current form is a landmine.

It's not a "landmine". It's how the POSIX permission system is implemented by file system drivers without support for it and it's sensible. The file system drivers usually support setting global permission masks. I suggest thinking about what would happen if a FAT32 filesystem or NTFS mounted without POSIX permission support returned errors on `chmod`. It would make it impossible for a user to choose to use a file system with only global permission bits for anything.

> Programs call APIs because they expect them to do something, so exposing an API that silently fails is an invitation to bugs

It's not a silent failure. The file system drivers are free to return `ENOSYS` but the default way of handling it is to use a global permission mask and disregard processes attempting to change it. Security is provided via the permissions on the path leading up to the mount point. For example, a local user plugging in a flash drive on a desktop environment like GNOME will have full permissions on the drive but other users (services, remote users or those at another "seat") will not. The decision about how to handle permissions is not made by the applications and it wouldn't make sense to return an error that they'd end up treating as a failure.

Can you explain a scenario where you think this design would cause an error?

> That it fails in the same way for FAT32 on Linux does not make it okay

It's how it works across platforms, not just Linux. Again, I suggest thinking about why it's done that way and what would happen if it returned errors.

> how many people are going to test with anything but the default file system?

I don't know what you mean. These permission systems involve the system as a whole and not an individual application. It also applies to any other permission system. For example, MAC labels will have no effect if the MAC system is set to a permissive / non-enforcing mode. Security involves getting it right at the application layer and the system configuration layer.

> At the very least, chmod should return an error if it isn't supported.

It shouldn't return an error if the file system uses a global mask instead of a per-inode one. That's not how permissions are intended to work.