[infinite-time future] sufficiently long tests can "deadlock" with the DUT

[nwf]

This is not likely to be a realistic problem for a while, just something noticed while reading, but in the interest of recording observations... Sockets have only finite buffers associated with them, so when doRFVIDII uses mapM_ over the sequence of DII packets to send the tests to the DUTs without reading from the corresponding RVFI streams, it's relying on being able to fit the entire test (and its RVFI replies) in socket buffers. Granted, the smallest test that will encounter this problem is one that overflows the sum of all four of QCVE's rcvbuf (holding processed RVFI messages), the DUT's sndbuf (ditto), the DUT's rcvbuf (holding DII packets), and QCVE's sndbuf (ditt), so that's probably rather sizable, but perhaps there's a concise way to rewrite trace evaluation as a fold of combined send-and-recvs (or as a pair of threads each folding, one doing the send and one doing the recvs, to still get the latency hiding benefits).

[PeterRugg]

Hmm, I think we have actually come across this (and increased sizes of our implementations' RVFI DII buffers to workaround it, which is definitely not ideal...). If memory serves, we may have tried interleaving at some point but the output was too confusing when one of the implementations crashed and we were seeing the messages interleaved. Still, should be an easy fix.