Avoid possible race-conditions related to openWriteOnlyFile

[slackner]

The current implementation of openWriteOnlyFile can lead to different race-conditions:

• Since openWriteOnlyLock is only used for opening files, stat-ing a file at the wrong time might reveal the temporary read-access set by openWriteOnlyFile. As a result, a program (e.g., a backup task) might see (and backup) the files with the wrong access mode. Maybe the lock should be used for even more functions? Maybe we should also use directory-specific locks to prevent slowing down other FUSE calls for unrelated directories?

• There is no protection for concurrent rename operations. If the file is replaced, we try to open the wrong file in the second openat call. This is also mostly harmless - but could lead to sporadic EACCES failures if the new file would also require the openWriteOnlyFile handling. We should either prevent concurrent renames - or, at least on Linux, we could use another variant of the /proc/self/fd/ trick: https://stackoverflow.com/questions/14514997/reopen-a-file-descriptor-with-another-access

Both of these issues are pretty harmless in practice, but it still doesn't hurt to think about possible solutions.