Fix OPEN30

For open replay, we need to track the directory cache entry pointer not
the resulting file cache entry pointer.

The entry is saved by Copy_nfs4_state_req and checked by
Check_nfs4_seqid when validating a replayed request.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Fix COMP5 for NFS v4.1

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Fix a problem uncovered by RNM20

Rename of file to a hard link to the file is directed by the RFCs to
do nothing. Code was not correctly handling and causing the "from"
name to be removed from Ganesha's directory cache.

The scenario in question is caused by the following sequence:

echo foo > /mnt4/file
ln /mnt4/file /mnt4/link
mv /mnt4/file /mnt4/link

It would appear that that should result in just one hard link to
the inode, named /mnt4/link, however, the RFCs specify that this
is a no-op operation, which means the file remains with two hard
links.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Properly fix CLOSE4

It turns out Ganesha really wasn't handling a CLOSE with an invalid
stateid properly. If we detect that the stateid belongs to a valid
clientid, we can return NFS4_OK, but in that case, we must also
update the lease.

We also need to make sure that ONLY CLOSE is affected by this
functionality. V4.1 also handles leases differently.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>