HAMMER 53H/Many: Performance tuning, bug fixes

HAMMER 53H/Many: Performance tuning, bug fixes

* CHANGE THE ON-MEDIA B-TREE STRUCTURE.  The number of elements per node has
  been increased from 16 to 64.  The intent is to reduce the number of seeks
  required in a heavy random-access loading situation.

* Add a shortcut to the B-Tree node scanning code (requires more testing).
  Instead of scanning linearly we do a power-of-2 narrowing search.

* Only do clustered reads for DATA types.  Do not cluster meta-data (aka
  B-Tree) I/O.  Note that the inode data structure is considered to be
  a DATA type.  Reduce the cluster read side from 256K to 64K to avoid
  blowing out the buffer cache.

* Augment hammer locks so one can discern between a normal lock blockage
  and one that is recovering from a deadlock.

* Change the slave work threads for the flusher to pull their work off a
  single queue.  This fixes an issue where one slave work thread would
  sometimes get a disproportionate percentage of the work and the
  master thread then had to wait for it to finish while the other work
  threads were twiddling their thumbs.

* Adjust the wait reclaims code to solve a long standing performance issue.
  The flusher could get so far behind that the system's buffer cache buffers
  would no longer have any locality of reference to what was being flushed,
  causing a massive drop in performance.

* Do not queue a dirty inode to the flusher unconditionally in the strategy
  write code.  Only do it if system resources appear to be stressed.
  The inode will get flushed when the filesystem syncs.

* Code cleanup.

* Fix a bug reported by Antonio Huete Jimenez related to 0-length writes
  not working properly.