LU-10192 osd-ldiskfs: create agent entry for remote entry

LU-10192 osd-ldiskfs: create agent entry for remote entry

In DNE environment, the object (in spite of regular file
or directory) and its name entry may reside on different
MDTs. Under such case, we will create an agent entry on
the MDT where the object resides. The agent entry references
the object locally, that makes the object to be visible to
the userspace when mounted as 'ldiskfs' directly. Then the
userspace tools, such as 'tar' can handle the object properly.

We handle the agent entry during set linkEA that is the common
interface for both regular file and directroy, can handle kinds
of cases, such as create/link/unlink/rename, and so on.

NOTE: we can NOT do that when ea_{insert,delete} that is only
for directory.

There are two known issues:
1. For one object, we will create at most one agent entry even if
   there may be more than one cross-MDTs hard links on the object.
   So the local e2fsck may claim that the object's nlink is larger
   than the name entries that reference such inode. And in further,
   the e2fsck will fix the nlink attribute to match the local
   references. Then it will cause the object's nlink attribute to
   be inconsistent with the global references. it is bad but not
   fatal. The ref_del() can handle the zero-referenced case. On the
   other hand, the global namespace LFSCK can repair the object's
   attribute according to the linkEA.
2. There may be too many hard links on the object as to its linkEA
   overflow, then the linkEA entry for cross-MDTs reference may be
   discarded. If such case happened, then at this point, we do not
   know whether there are some cross-MDTs reference. But there are
   local references, it guarantees that object is visible to
   userspace when mounted as 'ldiskfs'. That is enough.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ic9cc68a4dc864307dd5dd5fdb930bfac699c8379
Reviewed-on: https://review.whamcloud.com/29984
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>