Hello!

Describe the issue
fcntl F_DUPFD and F_DUPFD_CLOEXEC are not supported (for Epoll FDs) and cause a failure with EINVAL when creating a tokio runtime.

To Reproduce
Create a Rust Project using Tokio and attempt to build a Runtime like:

let runtime = tokio::runtime::Builder::new_multi_thread().enable_all().build().expect("build runtime");

This code panics with an std::io::Error containing EINVAL.

Operating System (please complete the following information):
Fedora 34

• Kernel version: post the output of uname -a

Linux wrex 5.13.15-200.fc34.x86_64 #1 SMP Wed Sep 8 15:51:46 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Shadow (please complete the following information):

** Starting Shadow v2.0.0-pre.4-198-gae248676-dirty 2021-09-14--14:21:38 with GLib v2.68.4

Additional context
In similar fashion to #1637 I'm trying to run a consensus protocol in shadow. This (currently released) project uses the tokio library for network IO. Unfortunately Tokio tries to immediately duplicate it's Epoll FD when the Runtime is created, causing creation to fail with EINVAL.

I was able to hack my was past this by simply returning the same FD for the F_DUPFD_CLOEXEC fcntl. This makes the project seem run fine (with the patch from #1637).

I am wondering what it would take to properly implement FD duplication (Epoll would be enough for me). From looking at the Code it seems like this would be a larger undertaking because the Epoll "Instance" and the FD live in the same object. At least I can't see an obvious way to have two FDs refer to the same Epoll.