color: recommend ICC file sealing

Previously the idea was to allow clients to just pass any regular file as an fd to the compositor if the file contains an ICC data chunk as-is, and not need to copy the ICC data.

Turns out this is dangerous to compositors. Regular files are defined to always poll as readable (POSIX), so receiving an fd pointing to a file on a slow disk or slow network file system is prone to stall the compositor, and polling for readable does not help. Since the file description is shared, the compositor cannot trust setting O_NONBLOCK anyway. Hence pread() is always dangerous. mmap() would have the usual SIGBUS hazards in addition.

Therefore, if the OS supports file sealing, require it. This makes mmap() safe, and the RAM location ensures it's not on a slow file system, so the compositor should not get stalled nor worry about SIGBUS.

Except, we cannot simply require file sealing on OSs that support it today, because an OS may add file sealing support in the future. Not having sealing support today but adding it in the future would retroactively change the impact of protocol specification, breaking clients that used to work. That is why sealing is only a recommandation and not a mandatory requirement by the spec.

On OSs where file sealing is not a thing, it is each compositor to their own how to best deal with the stalling and SIGBUS hazards. Probably a custom SIGBUS handler plus all file reading in a separate thread, or simply don't care.

The non-executable seems to be a recent'ish addition to memfd on Linux, and makes sense always anyway.

cc @leandrohrb