Clean up after false race fallout

[jacobsa]

Because of what appears to be a kernel bug, it looks like I was totally confused about the "race" in issue #3. In particular:

• The kernel guarantees that it will handle request serialization when the user expects it:

AFAIU, kernel fuse never sends next request before getting ACK for
previous one if user expects corresponding operations to be ordered.

• The fact that the "no msync, munmap before close" test fails when the write sleeps in the background and the flush is allowed to proceed appears to be a bug that was fixed somewhere between 3.13 and 3.16.

To do:

• Put some forensics in this thread about the bug, etc. Failure output and patches that can reproduce it. (Currently it can be reproduced at a191868279618d6882fe2f3281565bd956b14745, but that may be garbage collected.)
• Relax the stern warnings in the documentation about request serialization. Both in package fuse and package fuseops. Grep "FlushFileOp", "SyncFileOp", "parallel", "serial", "msyc". Do note the kernel bug, though.
• When updating the docs, do make sure to still pay attention to what OS X does.
• Consider making fileSystemServer call each file system method on its own goroutine. Also consider adding a flag-controlled random sleep at the start of the goroutine, to shake out further bugs.

[jacobsa]

Here is a gist containing a patch against dadff5d for reproducing, and output on two old machines (office Linux machine and GCE VM) and one new (GCE VM).

[jacobsa]

Maxim Patlasov points out that the bug was fixed by torvalds/linux@fe38d7d, for 3.15.