Implement blocking support for epoll

[tiif]

In #3712, any epoll_wait call with non-zero timeout value is currently rejected using throw_unsup_formatbecause blocking for file descriptions is not supported yet. This is part of the work for tokio support in #602 .

Below are some very high-level and rough steps that would be needed to support blocking epoll:

1. Refactor the main logic of epoll_wait into a function, as demonstrated in a1fc187. This can also be done together with the step below.
2. Use this.block_thread in epoll_wait, and this.unblock_thread in check_and_update_readiness.
   2.1 To get this.unblock_threadto work, we might need to introduce some data structures to know which thread should we wake up when there is an epoll notification for a file description.

@oli-obk mentioned an interesting test case that might be a data race on file description level: one thread close epoll file descriptor while another thread is blocking on that epoll file descriptor.

Visualisation:

thread 1                                     |  thread 2
epoll_wait on epoll file descriptor 5 blocks |
                                             |  close(5)
                                             |
                                             
                                             
> What should happen here? Reject the close or terminate the blocking operation? 

It seems like closing a file descriptor while blocking on it is UB, related SO discussion:

• https://stackoverflow.com/questions/40301754/c-blocking-read-should-return-if-filedescriptor-is-deleted
• https://stackoverflow.com/questions/543541/what-does-select2-do-if-you-close2-a-file-descriptor-in-a-separate-thread/546396#546396

[RalfJung]

It seems like closing a file descriptor while blocking on it is UB, related SO discussion:

I don't think it can be UB, the userspace - kernel interface doesn't usually have UB.

But "the blocked thread never wakes up" seems like a plausible outcome. If the close comes first, the read might actually read from a different file descriptor if a new file gets opened and assigned the same FD.

We don't do data race detection on file descriptors. So we could just let the blocked thread wait forever. We could also report this particular case with a dedicated diagnostic, but we shouldn't call it UB.

[tiif]

I forgot to link to this issue in #3804, closing this as done.