Fix race between parent and monitor in use_pty

[squell]

The problem with #1129 was two-fold:

1. When the monitor shuts down, it takes the pseudoterminal it controls with it. So we end up in a condition where the parent is racing with the monitor to read remaining data before the monitor crosses the finish line.

This could be demonstrated by adding a sleep in the monitor, but a better fix is simply to use the existing backchannel to synchronise parent and monitor. I re-used the old ExecCommand message for this, as that was already used to handle a similar race at the start.

So basically the backchannel protocol is: parent sends an Edge to signal the monitor it can go (this was already the case), do the usual thing while the monitor and child are doing their dance, and then again when the monitor has communicated that it is ended, let it wait for another Edge from the parent.

2. Secondly, the monitor is sending the "the child process has terminated" signal to the parent via backchannel communication, but the child is communicating itself the data over a pipe. It so happens that its final data is still in flight but overtaken by the backchannel.

The fix: in the flush_left function, also read the right side to completion.

[squell]

By the way, I have left b156eb9 in for illustration purposes only. That fix alone takes care of the problem "in practice". We can drop that one before it is merged.

[squell]

This fixes the problem on the FreeBSD machine I tested, but not on the Debian trixie machine.

[pvdrz]

I checked the changes and they totally make sens to me. However I was unable to reproduce this bug on my system so I don't have a proper way to see it working.

[squell]

While this fixes the problem on BSD for me, @rnijveld reported that it still happened for him even with this patch set. So that's why we haven't merged this yet.

[squell]

As for the final commit: the I/O subsystem doesn't know that the end of a pipe is at hand, since the child has stopped responding (but is being kept in suspended animation to avoid a "broken pipe").

So the solution that I used is to put the right end of the pipe in nonblocking mode, and then read until the OS indicates that a read on it will block (which signals the true end of the stream).

As far as I can tell, all the rest of our code will work fine with the Pty leader in nonblocking mode, but to avoid any changes in that part, I've only set it to 'nonblocking' before the final loop.

Since we're not going to be doing anything with the pipe after that, that is a conservative choice.

[squell]

I have investigated whether the "red light" synchronization mechanism is still necessary or merely reading from the Pty until exhaustion is enough. But on FreeBSD I've found that just the last two commits don't fix the problem. So we can't drop those.

[squell]

Seeing as this PR has been confirmed by @rnijveld to solve the problem and that the synch mechanism was also informally approved by @pvdrz I think we should now take this changeset. 🎈