Better handling of WA+RTE submissions to interactive problems.

[RagnarGrootKoerkamp]

Try to copy what https://github.com/DOMjudge/domjudge/commit/6a049540ac4f968165b38b087ac9721d16e2cc35 did.

[RagnarGrootKoerkamp]

The reason this works in DOMjudge:

All submission<->validator communication goes through the runpipe program, which alternatingly 'pumps' data from the submission to the validator and back, each time blocking for 1 millisecond to see if there's additional data to be pumped, and if not, switching to the other direction.

When a submission prints bad data and then exits with a non-zero return code, the following happens:

0. [optional] try pushing data from validator to submission. No such data exists so this blocks 1ms
1. push the bad output from the submission to the validator
2. try pushing from the validator to the submission for 1ms. In this 1ms, the validator won't print any output, but will exit with an error code to indicate WA. This will signal EOF to the stream, which unblocks the 1ms wait, and returns nread=0. This will check whether the submission is still running (it is, since we didn't get the eof/exit code yet, because everything happens synchronously), and conclude that the validator exists first.
3. Wait for submission to finish and give WA verdict.

In BAPCtools, I normally don't intercept the submission<->validator communication at all: they directly talk to each other via two pipes. In this setting, I can't check whether pipes are empty when the programs exit. One solution could be to have have different validator exit codes for WA because EOF is reached and WA because of actual bad output, but this is not compatible with the current setup of always returning 43 on WA.

I also have an option to pipe all submission<->validator communication through BAPCtools, but this happens in two asynchronous child programs currently, so it will still be hard to see what happens first.

If anybody sees a nice solution that keeps the pumping asynchronous, I'm happy to hear it. I don't really like the 1ms timeout in the current DOMjudge code (and this actually has a //FIXME next to it).

@meistert @SuprDewd

[mzuenni]

is this still an issue?

[RagnarGrootKoerkamp]

Hmmm, probably? By default the interactor still doesn't intercept communication, so while stuff has changed a bunch since this was created, the root issue is probably still there.

But I don't think there have been recent complaints about this so maybe also just close?

[mzuenni]

I would have hoped that waiting for the first program to terminate with wait4 might have solved this?

[RagnarGrootKoerkamp]

Ah right; that was added 9 months ago by you in #269, so probably this has been fixed then :)