This causes an INTERRUPT to happen, which is useful to see in
practice.

When adding a sleep to the READ operation, this yields the following
trace:

 rx 28: OPEN i2 {O_RDONLY,0x8000} 
 tx 28:     OK, {Fh 1 }
 rx 30: READ i2 {Fh 1 [0 +4096)  L 0 RDONLY,0x8000} 
 killing subprocess
 rx 32: FLUSH i2 {Fh 1} 
 tx 32:     OK
 rx 33: INTERRUPT i0 {ix 32} 
 tx 33:     OK
 tx 30:     OK,  1024b data "********"...
 rx 34: RELEASE i2 {Fh 1 0x8000  L0} 
 tx 34:     OK


ie. rather than canceling the READ, a FLUSH is issued which is then
INTERRUPTed.

Add stub implementations for the rest of the methods from the
Operations interface, and add a compile-time check that we don't
have missed any.

This should decrease confusion between Inode and Node

This lets filesystems control Generation produced. It also unifies
OpaqueID (used for implementors) NodeID (used for kernel comms) and
the Ino field (reported in Stat/Lstat calls).

For loopback, there is a minor inconvenience, which is that the file
is determined by (Dev, Ino). Get around this by xoring Dev and Ino.

Fix and test Nlink==0 test (issue #137)

Do not overwrite Attr.Ino, otherwise recycled inodes risk giving tools
like RSync the impression there are more hardlinks than there are.

identification

This fixes another possible race condition if the same file is looked
up through 2 different paths.

Remove FindChildByOpaqueID(), since it is still susceptible to race
conditions: two lookup calls might be racing, and both may see
FindChildByOpaqueID == nil, creating two Node objects

Instead, NewInode() automatically discards a new Node if it finds one
with existing opaqueID.

The FileID struct has (uint64,uint64) for Dev, Ino. While Dev
typically is uint32 (the FUSE protocol has uint32), it is uint64
analogous to syscall.Stat_t. The resulting 128 bits of ID space is
also ample space for storing hashes of other IDs (eg strings)

Inode.MvChild

Fix opaqueID

Nodes can become unused due to following reasons:

* no more children (see new RmChild function) 
* no kernel references (Forget)
* stop being persistent

If this happens, drop the node from the tree. Removals of nodes
cascade from leaves up to parents recursively

lookupCount is now protected by under Inode.mu

nodeID remains under bridge.mu

Co-author: navytux

Thanks to rfjakob for general feedback.

Next:
- add refctr like libfuse. Use it to implement persistent nodes 

TODO
- context for PID/caller
- Opendir

Open questions: grep for NOSUBMIT/TODO
- how many interfaces?
- explode SetAttr ?

Go-FUSE has been trailing the kernel, and the kernel (usually) is
careful to only send opcodes that are recognized. However, on GKE
(GCP) the undefined opcode 2016 has been seen, leading to a crash.

Fixes #276.

We usually were off by a factor of 256.
Fixes https://github.com/rfjakob/gocryptfs/issues/375

This reverts commit 9dcbb223.

Even though RELEASE is similar to FORGET, it must report back, or
tests will hang.

access(2) should check permissions of the caller UID/GID against file
permissions. In loopback, this may not be delegated to an access
syscall to the underlying file system, since that would use the
UID/GID of the FUSE process.

Use linear search to find requests to interrupt. This assumes that
interrupts are rare, and the number of outstanding requests when it
happens is low.

Interrupted requests are not put back into the request pool to avoid
racing with in-progress mutators.

INTERRUPT does not require a reply to the kernel. Trying to send it
yields

  writer: Write/Writev failed, err: 2=no such file or
  directory. opcode: INTERRUPT

In practice, this only triggers for RENAME_EXCHANGE, as the kernel
issues the RENAME opcode in case of a normal rename or a
RENAME_NOREPLACE.

We have always advertised rename2 support (protocol v23), but it returned
ENOSYS always. Instead, rename RenameIn => Rename1In, and add Flags to
RenameIn.

For raw filesystems that want to support rename2 should examine
RenameIn.Flags and check for syscall.RENAME_XXX.

For fuse/nodefs, we return ENOSYS in case of Rename2, since we lack
API surface to propagate the flags.

It is currently failing. Reported as
https://github.com/libfuse/libfuse/issues/362

After Linux VFS was enhanced to be able to do several lookups and
readdirs in parallel, FUSE client in Linux, in fear to break existing
filesystems, explicitly reverted it back to be serial in FUSE exchange
and requested filesystems to indicate via CAP_PARALLEL_DIROPS flag that
the filesystem server is ready to handle parallel lookup and readdir
requests.

	https://git.kernel.org/linus/5c672ab3f0

We should be ready to handle and we provide MountOptions.SingleThreaded
for those filesystems, which are not ready to handle requests in
parallel.