HAMMER 53A/Many: Read and write performance enhancements, etc.

HAMMER 53A/Many: Read and write performance enhancements, etc.

* Add hammer_io_direct_read().  For full-block reads this code allows
  a high-level frontend buffer cache buffer associated with the
  regular file vnode to directly access the underlying storage,
  instead of loading that storage via a hammer_buffer and bcopy()ing it.

* Add a write bypass, allowing the frontend to bypass the flusher and
  write full-blocks directly to the underlying storage, greatly improving
  frontend write performance.  Caveat: See note at bottom.

  The write bypass is implemented by adding a feature whereby the frontend
  can soft-reserve unused disk space on the physical media without having
  to interact (much) with on-disk meta-data structures.  This allows the
  frontend to flush high-level buffer cache buffers directly to disk
  and release the buffer for reuse by the system, resulting in very high
  write performance.

  To properly associate the reserved space with the filesystem so it can be
  accessed in later reads, an in-memory hammer_record is created referencing
  it.  This record is queued to the backend flusher for final disposition.
  The backend disposes of the record by inserting the appropriate B-Tree
  element and marking the storage as allocated.  At that point the storage
  becomes official.

* Clean up numerous procedures to support the above new features.  In
  particular, do a major cleanup of the cached truncation offset code
  (this is the code which allows HAMMER to implement wholely asynchronous
  truncate()/ftruncate() support.

  Also clean up the flusher triggering code, removing numerous hacks that
  had been in place to deal with the lack of a direct-write mechanism.

* Start working on statistics gathering to track record and B-Tree
  operations.

* CAVEAT: The backend flusher creates a significant cpu burden when flushing
  a large number of in-memory data records.  Even though the data itself
  has already been written to disk, there is currently a great deal of
  overhead involved in manipulating the B-Tree to insert the new records.
  Overall write performance will only be modestly improved until these
  code paths are optimized.