Document need for FSAL permission checking on directory mutating operations

Ganesha will not do any permission checking of directory mutating
operations in the upper layers. A directory mutating operation is any
operation that can add or remove names from a directory.

Two of these operations in particular are troublesome to do permission
checking in Ganesha because of races. Rename and unlink both have an
issue with atomicity of permission checking and operation. If the
permission check is not atomic with the operation, the permission check
could succeed, and then, before the operation proceeds, another user
does a rename, placing a different file under the guns of the rename or
unlink, the new file having permissions that prohibit the original user
from removing the file.

The various means of creating an entirely new directory entry are less
of an issue since they do not remove entries, however, many FSALs will
need to use the correct credentials for these operations for proper
quota accounting and enforcement, or simply to make sure the file is
atomically created with the correct owner. Given that these operations
are usually performed using the request credentials rather than root,
it is repetitive for Ganesha to make it's own permission determination.

Also, this makes for a simple rule. Any operation that changes the
contents of a directory will be permission checked at the bottom end.

Signed-off-by: Frank S. Filz <ffilz@us.ibm.com>
MORE Add fsal_set_credentials to fsal_symlink for FSAL_GPFS

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