LU-8900 snapshot: check write barrier before modification

LU-8900 snapshot: check write barrier before modification

For client sponsored modifications, the RPC service thread on the
MDT will check whether there is write barrier or not when creates
transaction handler, if yes, return -EINPROGRESS to the caller.

Generally, the check is done inside mdd_trans_create(). For those
cases that bypass mdd_trans_create(), such as some mdd_iocontrol,
quota, will be checked individually.

For open-unlink case, when close the last open handler, it will
try to destroy the orphan. But if the close-destroy is blocked
by the barrier, the orphan MDT-object will be kept in the MDT's
orphan list and will be destroyed automatically when remount the
MDT next time. Since barrier-snapshot is relative rare operation,
and race with close-destroy will be more rare, such solution is
reasonable and will not cause serious trouble.

When client get the -EINPROGRESS error, the expected behaviour is
to re-try the RPC some time later. That is the standard action on
the client-side, not only for blocked by barrier but also for some
cases, such as the case of related OI mapping is invaid and the OI
scrub is rebuilding the OI files. So there is no interoperability
trouble caused by MDT-side write barrier.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I8c3571f7f89fc9ff7397457955ffc75543eb2164
Reviewed-on: https://review.whamcloud.com/24264
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>