LU-1303 mds: integration lod/osp into the stack

 - config handler recognizes MDS config and replace LOV/OSC devices
   with LOD/OSP

 - the devices in MDS stack are setup from bottom to top using
   obd_connect() namely MDT->MDD->LOD->OSD, when new OSPs arrive,
   they connect to the OSD and LOD connects to every OSP). all the
   devices are referenced by exports, preventing them from early
   release.

 - once the whole configuration is processed, prepare() method of the
   top device is called, that in turn call ->prepare() down through
   the stack, etc. at this point the stack is considered ready to
   access storage, start recovery and do regular processing.

 - at umount ->ldo_process_config(LCFG_CLEANUP) is called down through
   the stack asking devices to release the resources (like objects
   referenced for internal purposes), then the series of calls to
   obd_disconnect()'s starting from the top MDT causes all the devices
   to become unreferenced and subject to release by zombie thread.

 - obd_notify() mechanism is not used by MDT/MDD/LOD/OSD, it's still
   used by OSP to be aware of current state:

      - to learn when the first connection to OST happens and let
        clients to connect to MDS, MDS uses obd_health_check() and
        caches positive result.

      - during object creation LOD uses dt_statfs() and data returned
        by OSP tells LOD whether specific OST active/inactive, space
        available, number of precreated objects, etc.

 - LOD takes care of striping: it maintains the list of available OST
   represented locally by OSP devices. on create, LOD finds suitable
   OSPs, create objects by means of OSD API and stores striping info
   into a local object. similarly LOD handles object destroy and
   UID/GID changes: load striping and execute on them.

 - llog is used by OSP as a local library, cookies are not visible out
   side of OSP. thus neither MDT nor MDD needs to care about cookies,
   prepare buffers. MDD doesn't need to send RPCs to destroy objects
   on behalf of evicted clients. all is hidden behind OSP's object
   destroy method.

 - OSP generates llog records for OST object being destroyed and, once
   corresponded local transaction is committed, send OST_DESTROY RPC.
   once OST_DESTROY is reported to be committed, corresponded llog
   record is cancelled.

 - the same logic is used for UID/GID changes.

Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Change-Id: Ifb282ace94f583ffa86020b763f22922e5d0b032
Reviewed-on: http://review.whamcloud.com/4087


Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Mike Pershin <tappro@whamcloud.com>