LU-5519 lfsck: repair slave LMV for striped directory

LU-5519 lfsck: repair slave LMV for striped directory

Before all shards of the striped directory scanned, the LFSCK
cannot know whether the master LMV EA is valid or not, and also
cannot know how to repair an invalid shard exactly. For example,
the stripe index stored in the shard's name does not match the
stripe index stored in the slave LMV EA, then the LFSCK cannot
know which one is correct. If the LFSCK just assumed one is
correct, and fixed the other, then as the LFSCK processing, it
may find that the former reparation is wrong and have to roll
back. Unfortunately, if some applications saw the changes and
made further modification based on such changes, then the roll
back is almost impossible.

To avoid above trouble, the LFSCK will double scan the master
object of the striped directory, that is NOT the same as normal
two-stages scanning, the double scanning the striped directory
will happen both during the first-stage scanning:

1) When the striped directory is opened for scanning, the LFSCK
   will iterate each shard in turn, and records its slave LMV EA
   in the lfsck_lmv::ll_lslr. In this step, if the 'shard' (may
   be fake shard) name does not match the shard naming rule, for
   example, it does not contain the shard's FID, or not contain
   index, then we can remove the bad name entry directly. But if
   the name is valid, but the shard has no slave LMV EA or the
   slave LMV EA does not match its name, then we just record
   related information in the lfsck_lmv::ll_lslr in RAM.

2) When all the known shards have been scanned, then the engine will
   generate a dummy request (via lfsck_namespace_close_dir) to tell
   the assistant thread that all the known shards have been scanned.
   Since the assistant has got the global knowledge about the index
   conflict, stripe count, hash type, and so on. Then the assistant
   thread will scan the lfsck_lmv::ll_lslr, and for every shard in
   the record, check and repair inconsistency.
2.1) If the shard lost its slave LMV EA, then regenerate the slave
     LMV EA.
2.2) If the index stored in the shard's name entry is wrong, then
     rename the shard.
2.3) If the shard's slave LMV EA contains bad index/stripe_count/
     hash type, then update the slave LMV EA.
2.4) If the shard object is missing, then re-create the lost shard.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I92c0bd569e5a2711b8c7e93904d050b3fdf35377
Reviewed-on: http://review.whamcloud.com/11848
Tested-by: Jenkins
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>