Investigate epoll performance when IO ratelimiting is in effect

When IO rate limiting is in effect, requests don't get serviced for a while (by design). This translates to the FD(s) in epoll not being *drained* for a while. During this time the epoll loop spams the Firecracker IO thread with events that are simply ignored down the line.

All that context switching incurs a performance penalty that we could eliminate by temporarily deregistering the rate-limited FD(s) from epoll while limiting is in effect.

We need to investigate whether de-registering and re-registering the FD(s) is overall more or less expensive than the spam of useless context switching.