Read multiple bytes for system events

[tlsomers]

When checking for system events, the current version would read 1 byte per iteration, meaning that when other tasks are ready, reading n bytes becomes interleaved with n other tasks. These tasks may be slow, resulting in unnecessary slowdowns of system events (such as UI events in vscoq).

This change allows reading another byte from its file descriptor when:

1. The system event has lower priority than the lowest priority ready event
2. The event just read an available byte from the file descriptor.

[gares]

Thanks for your contribution, I'll try to double check the code again on Monday, but it looks OK to me.
One thing I'd like to have is a test. I think you can verify the invariant by using 2 pipes and two events of different priorities.
You can then check the second pipe is still full after sel returns with the first event being ready.
Some benchmarking would also be nice, but I don't have a proper infrastructure.

There is another approach that may be worth considering:

• read more data here
  

  sel/lib/events.ml

  Line 205 in bccdff5

  let n = Unix.read fd buff 0 1 in

• pass the extra data (after the \n) to the following event:
  

  sel/lib/events.ml

  Lines 166 to 170 in bccdff5

  	one_line ()
  	--? (parse_content_length_or (finish_with k) (fun length ->
  	one_line ()
  	--? (fun _discard ->
  	some_bytes length ()

I suspect that VSCode sends the whole header in one go (and maybe also the payload). In this way the number of iterations of the loop pulling ready events is going to decrease substantially.