poll for TIOCINQ and TIOCOUTQ instead of POLLIN, bump repeats

[jackyzha0]

we noticed a few cases where if a program exited really quickly but dumped a lot of output (e.g. env in the replit shell) we could sometimes miss output

we used to poll the controller side fd for POLLIN but that actually isn't fully correct.

the tty pipes look something like:

controlling program <> controller fd <> user fd <> user program
|---user space------||--------kernel space------||-user space-|

we can sometimes enter cases where the controller side thinks it has no more data to give to the controlling program (nodejs when using @replit/ruspty) but the kernel has decided to block on passing some user fd data to the controller fd (on linux for example, the pipe in the user fd -> controller fd direction has about 4kb of capacity)

for example, if node isnt processing data events quickly enough, the controller-side queue can fill up and the user fd write will block until it has space again, we could rarely enter a race if nodejs decides to read an entire 4kb block completely emptying the controller fd queue and then the POLLIN logic could return with no more data left (even though the user side still has a pending write!)

this would drop data :(

a few changes:

• rust-side
  • poll TIOCINQ and TIOCOUTQ on controller and user instead of just POLLIN on controller
• wrapper level
  • trigger 'end' event on the read stream on EIO instead of just calling the cb (that way, other things with handles to the socket can also handle end appropriately)
  • exit condition is now
    • fd closed && fd fully read && program actually exited
• test level
  • bump repeats from 50 -> 500
  • rewrite it to a more standard async format so errors during the test actually are associated with that test
  • added a test for fast output (>4kb output and fast exit)

[blast-hardcheese]

v. nice

[lhchavez]