LU-4604 lfsck: LFSCK async updates RPC flow control

LU-4604 lfsck: LFSCK async updates RPC flow control

Control the max in flight async updates RPCs count in OSP layer to
avoid too much in flight RPCs causes memory issue and OST overload.

Currently, we use a semaphore for that which is initialized as 512.

It also contains the layout LFSCK performance tests:
1) lfsck_layout performance under single MDS mode with kinds of
   stripe counts and kinds of file sets, for routine check case
   and repairing case.

2) lfsck_layout performance under DNE mode with kinds of file
   sets, for routine check case and repairing case.

3) lfsck_layout impact on create performance.

This patch also fixes some bugs related with lu_device_type
operations smooth the lfsck performance test.

There was no protection when inc/dec lu_device_type::ldt_device_nr,
which may caused the ldt_device_nr to be wrong and trigger assert.
This patch redefine lu_device_type::ldt_device_nr as atomic type.

There was no protection when add/del lu_device_type::ldt_linkage
into/from the global lu_device_types list, which may caused bad
address accessing. This patch uses the existing obd_types_lock
to protect related operations.

We do NOT need lu_types_stop() any longer. Such function scans
the global lu_device_types list, and for each type item on it
which has zerod lu_device_type::ldt_device_nr, call its stop()
method. In fact, the lu_device_type::ldt_device_nr only will be
zero when the last lu_device_fini() is called, and at that time,
inside the lu_device_fini(), its stop() method will be called.
So it is unnecessary to call the stop() again via lu_types_stop().

Test-Parameters: mdtcount=2 ostcount=2 envdefinitions=SLOW=yes testlist=lfsck-performance
Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: Ib9bae6ad0446e8705fa2767d080150e82a495e2f
Reviewed-on: http://review.whamcloud.com/8694
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Jian Yu <jian.yu@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>