LU-8900 snapshot: operate write barrier on MDT

LU-8900 snapshot: operate write barrier on MDT

Currently, the Lustre barrier is implemented as write barrier
on all MDTs. For each MDT in the system, when it starts, it
registers a barrier instance that will be used in handling
subsequent barrier requests.

The barrier_handler() processes the barrier request: freeze
or thaw the barrier on the MDT. Freezing barrier is the key
part. We use two-phases barrier to guarantee that after the
barrier setup:

1) All the MDT side pending async modifications have been flushed.
2) Any subsequent modification will be blocked.
3) All async transactions on the MDTs have been committed.

For phase1, we do the following:

Firstly, it sets barrier flag on the instance that will block
subsequent modifications from clients. (Note: server sponsored
modification will be allowed for flush pending modifications)

Secondly, it will flush all pending modification via dt_sync(),
such as async OST-object destroy, async OST-object owner changes,
and so on.

If there are some on-handling clients sponsored modifications
during the barrier freezing, then related modifications may cause
pending requests after the first dt_sync(), so call dt_sync()
again after all on-handling modifications done.

With the phase1 barrier set, all pending cross-servers modification
have been flushed to remote servers, and any new modification will
be blocked. But it does not guarantees that all the updates have been
committed to storage on remote servers. So when all the instances
have done phase1 barrier successfully, the MGS will notify all
instances to do the phase2 barrier as following:

Every barrier instance will call dt_sync() to make all async
transactions to be committed locally.

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