nfs4: support hard links properly

The main purpose of this patch is to prevent VFS from removing a vnode to early
what might have happened if the NFS client knew it had more than one name but
then one of them was deleted. Moreover, all discovered and still valid names
are stored what may be useful in proper file handle recovery when they are
volatile.

This patch fixes both #9558 and #9561.

nfs4: Introduce VnodeToInode mapping

VnodeToInode is another abstraction layer between VFS vnodes and NFS nodes.
It simplifies dealing with race conditions as well as faking some guarantees
VFS expects but NFS does not provide.

nfs4: Fix race condition between inode creation and removal

If the underlying file system reuses inode numbers it is possible that
an entry of inode with reused id in InodeIdMap will be removed.
This patch should also improve behavior when one of many hard links
is removed.

nfs4: Add numerous assertion checks

nfs4: Fix file handle recovery

nfs4: Use one open state per inode

nfs4: Move file handle recovery code out of Inode class

nfs4: Use MutexLocker for locking

nfs4: Remove unused entries from inode number to filehandle map

nfs4: Add support for volatile filehandles

nfs4: Partial support for servers not providing FileId

nfs4: Inodes should know their name and parent's filehandle

nfs4: Add lookup() and get_vnode() hooks

get_vnode() needs a way to retrieve filehandle knowing only inode number.
Since NFS4 sever does not provide such services client manages its own mapping
between ino_t and filehandles.

nfs4: support hard links properly

The main purpose of this patch is to prevent VFS from removing a vnode to early
what might have happened if the NFS client knew it had more than one name but
then one of them was deleted. Moreover, all discovered and still valid names
are stored what may be useful in proper file handle recovery when they are
volatile.

This patch fixes both #9558 and #9561.

nfs4: Introduce VnodeToInode mapping

VnodeToInode is another abstraction layer between VFS vnodes and NFS nodes.
It simplifies dealing with race conditions as well as faking some guarantees
VFS expects but NFS does not provide.

nfs4: Fix race condition between inode creation and removal

If the underlying file system reuses inode numbers it is possible that
an entry of inode with reused id in InodeIdMap will be removed.
This patch should also improve behavior when one of many hard links
is removed.

nfs4: Add numerous assertion checks

nfs4: Fix file handle recovery

nfs4: Use one open state per inode

nfs4: Move file handle recovery code out of Inode class

nfs4: Use MutexLocker for locking

nfs4: Remove unused entries from inode number to filehandle map

nfs4: Add support for volatile filehandles

nfs4: Partial support for servers not providing FileId

nfs4: Inodes should know their name and parent's filehandle

nfs4: Add lookup() and get_vnode() hooks

get_vnode() needs a way to retrieve filehandle knowing only inode number.
Since NFS4 sever does not provide such services client manages its own mapping
between ino_t and filehandles.