Speed up lock manager during bulk operations

[overheadhunter]

As suggested in this thread, there might be room for improvements in the locking scheme implemented in #15:

Since the modification of the directory resource happens atomically when actually adding/removing a child, it might be worth trying to only get a shared read lock on a directory when adding or removing children. This is more of a eventual consistency model. I.e. a concurrent directory listing will be undefined.

When creating, deleting or moving a directory, we still need an exclusive write lock on that directory. During that time no read lock can be obtained, thus modifications to ancestors will not be possible.

Todo

• profile application while adding a single large directory (deeply nested)
• decide whether lock contention can be reduced on directory locks
• (optionally) only "read-lock" directories when adding or removing children

[overheadhunter]

I added a directory a/b/c/d/e containing 500 4-byte-files. The work was done by 5 FUSE threads, all behaving similar. We see that the actual locking isn't taking much time, but the recursion does:

[overheadhunter]

Lock contention is not a problem.

However, the locking mechanism could be sped up significantly by reducing conversions between List<String> pathComponents and String path:

We now have more than 10k invocations in 927ms, where we had 5.5k before in 986ms before.