HAMMER 56C/Many: Performance tuning - MEDIA STRUCTURES CHANGED!

HAMMER 56C/Many: Performance tuning - MEDIA STRUCTURES CHANGED!

* Implement variable block sizes.  Records at offsets < 1MB use 16K buffers
  while records at offsets >= 1MB use 64K buffers.  This improves performance
  primarily by reducing the number of B-Tree elements we have to stuff.

* Mess around with the deadlock handling code a bit.  It still needs
  a re-think but it works.  Implement low-priority shared locks.
  A low priority shared lock can only be acquired if no other locks are
  held by the thread.

* Implement slow-down code for the record backlog to the flusher and
  reimplement the slow-down code that deals with reclaimed inodes queued
  to the flusher.  This should hopefully fix the kernel memory exhaustion
  issues for M_HAMMER.

* Update layer2->append_off.  It isn't implemented yet but doing this now
  will prevent media incompatibilities later on when it does get implemented.

* Split hammer_blockmap_free() into hammer_blockmap_free() and
  hammer_blockmap_finalize().

* Fix a bug in the delayed-CRC handling related to reblocking.  When
  throwing away a modified buffer, pending CRC requests must also be
  thrown away.

* Fix a bug in the record overlap compare code.  If we cannot return 0
  due to an overlap because the record has been deleted, we must still
  return an appropriate formal code so the scan progresses in the
  correct direction down the red-black tree.

* Make data in the meta-data zone a meta-data buffer structure type so
  it gets synced to disk at the appropriate time.  This may be temporary,
  it's needed to deal with the atime/mtime code but another commit may
  soon make it moot.

* Bump the seqcount so cluster_read() does the right thing when reading
  into a large UIO just after opening a file.

* Do a better job calculating vap->va_bytes.  It's still fake, but its a
  more accurate fake.

* Fix an issue in the BMAP code related to ranges that do not cover the
  requested logical offset.

* Fix a bug in the blockmap code.  If a reservation is released without
  finalizing any allocations within that big-block, another zone can steal
  it out from under the current zone's next_offset, resulting in a zone
  mismatch panic.