[LibOS] Wrong semantics (+bug) of `poll`/`select` on fd `0` ("dev:tty")

[boryspoplawski]

Description of the problem

Doing poll or select (or any of their variants) on fd 0 returns immediately and indicates the fd is ready for reading even if there is no data available.
There is a bug here:
https://github.com/oscarlab/graphene/blob/df5882b02b8e59b7d3827842dd9f10c903492032/LibOS/shim/src/sys/shim_poll.c#L117
there is no error checking, hdl->fs->fs_ops->poll returns -EAGAIN which is interpreted as a bitmap of events.

There is also another problem: these fd specific polls should be only called on fds which have non-blocking polls (only I can think of is a regular file), otherwise we can block there even if other fd would report some conditions. For some reason fd0 which is actually a "dev:tty" is handled by chroot fs code (tho it's considered a FILE_TTY)

Steps to reproduce

Just try POLLIN on fd 0.

[dimakuv]

@boryspoplawski Do you want to fix it? The first bug is simple (checking return value of poll()), but the second problem seems more complex. I will assign a low priority for it now.

[boryspoplawski]

@pwmarcz is reworking fs stuff, so I didn't want to get in his way...
I did not submit a PR on the first bug since it wouldn't solve the original issue (polling on 0), so this can be fixed all at once.