LU-7256 tests: wait current LFSCK to exit before next test

LU-7256 tests: wait current LFSCK to exit before next test

During the sanity-lfsck tests, some test cases only check the
LFSCK status on MDT0, and go ahead if the status matches the
expected one. For DNE cases, such check maybe not enough, and
may leave un-finished LFSCK instances on other MDT(s). It may
cause the following trouble:

1) When move to next test case, the un-finished LFSCK instance
   may cause new LFSCK instance failure or other strange LFSCK
   check/repair behaviour.

2) If it is the last test case, and some MDT(s) umounted, then
   when some un-finished LFSCK instance on another online MDT
   needs to talk with some umounted MDT, then related RPC will
   trigger reconnect to the umounted MDT, and the LFSCK engine
   will hung there till such MDT mount again. That is the case
   for this ticket hit. In fact, we should allow the server to
   umount even though some LFSCK instances run on other nodes.
   The LU-6684 patch (http://review.whamcloud.com/#/c/17032/)
   will handle that more properly.

This patch is mainly for adjusting test scripts to wait all
the LFSCK instances to exit before the next test case.

There are two options to wait all the LFSCK instances to exit:

1) Check the LFSCK status via related lproc interface on each
   target (MDT/OST) one by one.

2) Export some new interface to check all the LFSCK instances'
   status via single command.

We choose the later solution. Because it is convenient for the
sys-admin. The new interface is 'lctl lfsck_query'. Its usage:

lctl lfsck_query <-M | --device MDT_device> [-h | --help]
                 [-t | --type check_type[,check_type...]]
                 [-w | --wait]

options:
-M: device to query LFSCK on.
-t: LFSCK type(s) to be queried (default is all).
-w: do not return until LFSCK not running.
-h: help message.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I0bdab85e47eb290bfe3605dfc37caf7ea35d186a
Reviewed-on: http://review.whamcloud.com/17406
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Jian Yu <jian.yu@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>