Fixup cache_inode_create in light of permissions work

Permission checking for create will be accomplished by the FSAL.

It SHOULD be accomplished by passing the user creds to the kernel or
whatever ultimately does the operation.

However we need to properly update parent directory attributes.

Signed-off-by: Frank Filz <ffilz@us.ibm.com>
Strip permission check cache_inode_link

Permission checking for link will be accomplished by the FSAL.

It SHOULD be accomplished by passing the user creds to the kernel or
whatever ultimately does the operation.

Signed-off-by: Frank Filz <ffilz@us.ibm.com>
Properly permission check cache_inode_rdwr

Permission checking will actually be done at protocol layer.

For NFS v4, we do permission checking on OPEN and on READ and WRITE
operations that use a special stateid.

NFS v3 operations as well as NFS v4 operations performed with a special
stateid will bypass permission checking if the user is the owner of the
file. This is in order to support client side POSIX behavior where a
file may be opened and then the permissions changed without affecting
the open (open(O_CREAT) may have the same effect). Since we don't have
a protocol open, we can not assume the file permissions have not
changed. The client will make an ACCESS call in conjunction with any
open system call that will verify if the open is allowed.

This "owner bypass" check must be done by the protocol layer and not
in the access check code. If done in the access check code, it would
confuse the ACCRESS operation.

NFS v4 OPEN will also result in read, write, or read/write permission
checking based on the type of open.

In all cases, a READ operation, or open for read only is also allowed
if the user has execute permission but not read permission. This is to
allow the client to read executables that do not allow read permission.
The client also has responsibility to make this work. If the client
makes an ACCESS call, read will be denied if the file is execute only.
Not all clients handle this condition properly, or do not handle it
properly for all types of executables.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
Strip permission checking from cache_inode_remove

Permission checking will be done by underlying filesystem under FSAL.

Also, don't call cache_inode_remove_impl to remove the entry to
be overwritten. That will be taken care of by rename op and
cache_inode_add_cached_dirent.

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

Callers should let cache_inode_rename, and ultimately FSAL_rename do the
checking of various things. This allows checks for things like empty
directories before overwrite to be done by the actual atomic operation
and not dependent on our cache.

Trim down when cache_inode_rename holds content_lock.

Also, for NFS v3, we do the get post op attr in the operation rather than
burdening cache_inode_rename with it.

All callers of cache_inode_lookup_impl needed to take content_lock around
the call. Instead of making callers do it, push the lock/unlock into
cache_inode_lookup_impl.

If todir/newname exists, we handle removing the cache entry AFTER the
FSAL_rename code, rather than using cache_inode_remove. This makes the
operation more atomic.

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