LU-5180 lfsck: linkea for orphan

To make the fid2path tools can work against any client visible
object, the LFSCK will generate linkEA not only for the orphan
under the directory /ROOT/.lustre/lost+found/MDTxxxx/ but also
for the objects ".lustre" and ".lustre/lost+found".

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ibf957e8e2ec93d0f8f8a7cf1ac45706fb79a41db
Reviewed-on: http://review.whamcloud.com/10733
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: wangdi <di.wang@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
LU-5099 api: transfer object type via dt_insert API

When the LFSCK finds a dangling name entry, it may be required to
re-create the lost remote MDT-object. The LFSCK needs to know the
file type for the re-creating.

Generally, the LFSCK can get the file type from the name entry.
Unfortunately, when we insert the name entry into the directory
via dt_insert(), the sponsor does not transfer the object type.
It is not a problem for local case, because the OSD can get the
file type internally via checking the MDT-object directly. But
for remote case, when the OSD handles insert locally for remote
object, it cannot get the remote object type. On the other hand,
in DNE I, only directory can be remote, the OSD can assume that
the file type is S_IFDIR. But such assumption will be wrong when
enable remote object for normal file and will misguide the LFSCK
to re-create worng MDT-object.

This patch enhances the dt_insert() and dt_declare_insert() API
parameter to allow the insert operation sponsor to transfer the
file type directly.

The patch also changes the wire protocol for OUT_INDEX_INSERT
to transfer file type from one MDT to another.

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