LU-8288 lfsck: handle dangling LOV EA reference

LU-8288 lfsck: handle dangling LOV EA reference

Originally, the layout LFSCK logic of handling dangling LOV EA
reference is as following:

During the first phase scanning, if the layout LFSCK find that
some LOV EA entry references an OST-object that does not exist,
then it will repair the inconsistency based on the LFSCK start
parameter "-c" option. If "-c" option is specified, the layout
LFSCK will think the OST-object lost, then it will create the
lost OST-object with the FID that is stored in the LOV EA slot.
But such repairing may be incorrect. Because the LOV EA may be
corrupted as to the LOV EA is invalid. Means the OST-object is
still on the OST. When moves to the second stage scaning, the
layout LFSCK will find the orphan OST-object that claims to be
as one of the MDT-object's stripe. And if someone has already
modified the new created OST-object before finding the orphan,
then the layout LFSCK cannot recover the original data back.

To avoid above trouble, the patch introduces new start option:
"--delay-create-ostobj" or short described as "-d". It allows
the layout LFSCK to postpone creating the "lost" OST-object
until all the orphan OST-objects handled. It will record the
dangling references in some new introduced layout LFSCK trace
files on disk during the layout LFSCK first stage scanning,
then travel those traces file after all orphan OST-objects
handled in the second-stage scanning. The side-effect of such
option is that as long as one OST does not join the layout
LFSCK or fail to complete the scanning, then reparing dangling
LOV EA will be skipped. For a large system with a lot of OSTs,
such condition may be a bit strict. The default value is 'off'.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ic222e1ad20c8011aa5f41cc43171d017ab5c464f
Reviewed-on: https://review.whamcloud.com/21562
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>