LU-3336 lfsck: namespace visible lost+found directory

LU-3336 lfsck: namespace visible lost+found directory

The LFSCK will create the lost MDT-objects under a namespace visible
directory, then the admin can future handle those orphans with human
knowledge later.

The directory is named as "lost+found" under ".lustre", which is not
the same as backend (for ldiskfs case) "/lost+found". The latter one
is invisible from Lustre namespace. Under ".lustre/lost+found/", the
LFSCK will create sub-directory "MDTxxxx" for each MDT. (xxxx is the
MDT number)

The ".lustre/lost+found" uses special FID:

enum dot_lustre_oid {
        FID_OID_DOT_LUSTRE      = 1UL,
        FID_OID_DOT_LUSTRE_OBF  = 2UL,
        FID_OID_DOT_LUSTRE_LPF  = 3UL,
};

const struct lu_fid LU_LPF_FID = { .f_seq = FID_SEQ_DOT_LUSTRE,
                                   .f_oid = FID_OID_DOT_LUSTRE_LPF,
                                   .f_ver = 0x0000000000000000 };

Both ".lustre" and its child "lost+found" reside on the MDT0. As for
the "lost+found"'s children "MDTxxxx" uses normal FID and resides on
the corresponding MDT. The orphans will be linked under the "MDTxxx"
by the LFSCK on such MDT when it find the orphans.

The ".lustre/lost+found" is created by the MDT0 when mdd_prepare().
The ".lustre/lost+found/MDTxxxx" is created by the LFSCK on related
MDT when it needs to process orphans. (create on demand)

The permission for ".lustre/lost+found" is "r-x------" for root user.
Only the LFSCK can create sub-directories "MDTxxxx" under it. All the
other modifications are denied.

The permission for ".lustre/lost+found/MDTxxxx" is "rwx------" for
root user. Any modification is the same as operated on normal file.

The lost+found mechanism is not only for LFSCK phase II but also for
other LFSCK orphan handling. Since it is visible to Lustre namespace,
the admin can operate the orphans as other normal files easily.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Idd37c87c2517175022127a2a605ebb3ddf1f223a
Reviewed-on: http://review.whamcloud.com/8305
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>