LU-4588 code: replace semaphores with mutexes

It's just optimization. The mutex subsystem is slightly faster
and has better scalability for contended workloads.

Remove the lustre_lock and it's accessor functions l_lock(),
l_unlock(), l_lock_init(), and l_has_lock() since they have
not been used by the code since Lustre 1.6.

Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
Change-Id: I1b6defe7bdea2f7b33638a98c73277290c10bea1
Reviewed-on: http://review.whamcloud.com/9294
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
LU-4257 clio: replace semaphore with mutex

According https://www.kernel.org/doc/Documentation/mutex-design.txt:
 - the mutex subsystem is slightly faster and has better scalability
   for contended workloads. In terms of 'ops per CPU cycle', the
   semaphore kernel performed 551 ops/sec per 1% of CPU time used,
   while the mutex kernel performed 3825 ops/sec per 1% of CPU time
   used - it was 6.9 times more efficient.
 - there are no fastpath tradeoffs, the mutex fastpath is just as
   tight as the semaphore fastpath. On x86, the locking fastpath is
   2 instructions.
 - 'struct mutex' semantics are well-defined and are enforced if
   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand
   have virtually no debugging code or instrumentation.

One more benefit of mutex is optimistic spinning. It try to spin for
acquisition when there are no pending waiters and the lock owner is
currently running on a (different) CPU. The rationale is that if the
lock owner is running, it is likely to release the lock soon.

This significantly reduce amount of context switches when locked
region is small and we have high contention.

Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
Change-Id: Ic13179ab7e5ee628f550e5dfd251af31ac6d4211
Reviewed-on: http://review.whamcloud.com/9095
Tested-by: Jenkins
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>