Tester opens way too many files

[MattWindsor91]

And possibly doesn't close them possibly, leading to runs constantly failing with too many open files.

I've done a lot of rounds of trying to find file leaks, but none seem to be showing up, meaning this is possibly just a case of, well, opening too many files at once.

Some mitigations in the interim could include making sure we don't parallelise on large corpi directly (instead, use a worker pool); trying to push worker pools more pervasively (deeply nested parallelisations within parallelisations might be blowing up combinatorial); and fixing the harness overspecialisation issue (which I'll file an issue for next).

[MattWindsor91]

This is still an issue, despite a few attempts to try to address it. Some mostly circumstantial observations:

• It seems to take about 3 days to happen every time
• The ulimit of the machine we're testing on is 1024, so it seems like a slow trickle of file loss
• We deal with an input corpus of over 1024 files, so it doesn't seem to be in the initial planning section

[MattWindsor91]

After running the tester for several weeks on end, there have been no file exhaustion crashes. I'm satisfied that this is no longer an issue, and that the fix was indeed related to buggy SSH code. Closing.