LU-5508 osp: RPC adjustment for remote transaction

LU-5508 osp: RPC adjustment for remote transaction

1) For remote transaction, the set_attr/set_xattr RPC should not be
   prepared in declare phase. According to our current transaction/
   dt_object_lock framework, the transaction sponsor will start the
   transaction firstly, then try to acquire related dt_object_lock
   if needed. That is a general rule, and the LFSCK needs to follow
   such rule when repair inconsistent linkEA, in spite of local or
   remote MDT-object.

   For linkEA repairing case, before the LFSCK thread obtained the
   dt_object_lock on the target MDT-object, it cannot know whether
   the MDT-object has linkEA or not, neither invalid or not.

   Since the LFSCK cannot hold dt_object_lock before the (remote)
   transaction start (otherwise there will be potential deadlock),
   it cannot prepare related RPC for repairing during the declare
   phase as other normal transactions do.

   To resolve the trouble, we will make OSP to prepare related RPC
   (set_attr/set_xattr/del_xattr) after remote transaction started,
   and trigger the remote updating (RPC sending) when trans_stop.
   Then the up layer users, such as LFSCK, can follow the general
   rule to handle trans_start/dt_object_lock for repairing linkEA
   inconsistency without distinguishing remote MDT-object.

2) Some adjustment for OSP object attributes cache maintainig to make
   the logic more clear and reasonable.
2.1) Update the cached attribute in osp_attr_set(), but not in the
     osp_declare_attr_set().
2.2) Update the cached extended attribute in osp_xattr_set(), but not
     in the osp_declare_xattr_set().
2.3) Drop the cached extended attribute in osp_xattr_del().

3) Typo fixing and code cleanup.

Signed-off-by: Fan Yong <fan.yong@intel.com>
Change-Id: I43c88a8fd3b184c91a4b3cbd4104e35f9915ee24
Reviewed-on: http://review.whamcloud.com/11382
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>