hDuplicateTo001 fragile under CI

In this build (x86_64-linux-deb9-debug job) the hDuplicateTo001 test failed with:

Wrong exit code for hDuplicateTo001(threaded2)(expected 0 , actual 1 )
Stderr ( hDuplicateTo001 ):
hDuplicateTo001: tmp: hDuplicateTo: resource busy (Device or resource busy)
*** unexpected failure for hDuplicateTo001(threaded2)

This is the only time I have seen this failure.

I believe hDuplicateTo ultimately calls dup2 (see GHC.IO.Handle.dupHandleTo). The manpage for dup2 claims that this error might be returned if:

       EBUSY  (Linux only) This may be returned by dup2() or dup3() during a race condition with open(2) and dup().

In other words, we asked the kernel to make the file descriptor dest a duplicate of handle src, but while this operation was underway another thread allocated dest.

It's rather unclear what to do here. I can see how this would happen but it's quite unclear what we can do about this. It seems to me like it is nearly impossible to use this operation in the threaded runtime, given how little control you have over when and how fds are allocated.

I'm going to disable this test in the threaded way.