Use fsal_filesystem in FSAL_VFS to support multiple filesystems and extract FSAL_XFS

This is a major change...

XFS is now handled by FSAL_XFS:
-------------------------------

FSAL_XFS shares most of it's code (static linking) with FSAL_VFS, but is
now a separate loadable FSAL module. That helps in the handling of
filesystem claims.

The VFS handle has been reformatted:
------------------------------------

Now Linux core VFS, FREEBSD, and XFS each have their own handle format.
The FREEBSD and XFS handles already had an fsid in them. The format of
the core Linux handle is:

/* Visual handle format
 *
 * 1 byte		handle_len (doesn't go on wire)
 * 1 byte		flags
 *				00xxxxxx fsid_type
 *				01000000 handle_type fits in one byte
 *				10000000 handle_type fits in two bytes
 *				11000000 handle_type fits in four bytes
 */
 /*
 * 0, 8, or 16 bytes	fsid type
 * 1,2 or 4 bytes 	handle type
 * 12 to 40 bytes	opaque kernel handle
 *
 * NOTE: if handle type doesn't fit in 2 bytes or less, 40 byte handles
 *	 (BTRFS and GPFS are known file systems that use 40 bytes) are
 *	 incompatible with 16 byte uuid form fsids.
 *	 If VMware clients are concerned, the limit is 8 bytes less...
 */

FREEBSD and XFS file systems will use the fsid from the handle:
---------------------------------------------------------------
These filesystems will automatically be re-indexed.

Configurable fsid type for FSAL_VFS exports:
--------------------------------------------

The FSAL configuration for an export may specify the fsid type.
This really only applies to core Linux filesystems. The types are:

None
One64 (one uint64_t)
Major64 two uint64_t but only major is indexed)
Two64 (two uint64_t)
uuid  (synonym for Two64)
Two32 (two uint32_t)
Dev (two uint32_t using the device major.minor)
Device (synonym for Dev)

Support crossing filesystem junctions:
--------------------------------------

An FSAL lookup that crosses a filesystem boundary will be properly
handled, with fsid changing and everything. This allows sub-mounted
fileysystems to work properly for both NFS v3 (at least with the Linux
client) and NFS v4 (with any client that crosses filesystem boundaries).

The fsid for the filesystem is used for fsid in getattrs:
---------------------------------------------------------

Instead of filling in fsid from st_dev, the fsid from the
fsal_filesystem is used.

Allows for crossing of FSAL boundaries from FSAL_VFS or FSAL_XFS:
-----------------------------------------------------------------

Improve handling of crossing FSAL boundaries in POSIX namespace

Take the following filesystems:

/export/xfs
/export/xfs/some/path/ext4

Assume /export/xfs is exported FSAL_XFS and /export/xfs/some/path/ext4
is exported FSAL_VFS. The directory /export/xfs/some/path/ext4 must
have two cache inodes, one that looks like an FSAL_XFS inode, and one
that looks like an FSAL_VFS inode. These are required to make the
export junction work.

Of course xfs can not do name_to_handle_at on
/export/xfs/some/path/ext4. When we get an error back from that
call, we just invent a handle (basically just the fsid wich will
not conflict with any FSAL_VFS or FSAL_XFS handle.

This handle can be found by LOOKUP and READDIR. It may be used for
GETATTR. All other operations will result in XDEV error.

------------------------------------------------------
Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Simplify vfs_stat_by_handle

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Use fsal_filesystem in FSAL_GPFS to refine multiple filesystem support

With this change, FSAL_GPFS now supports sub-mounted filesystems as part
of an export.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
Handle EXDEV in cache_inode_readdir

The current implementation of this is to ignore the entry and not
have it present.

Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>