kernel - Even more buffer cache / VM coherency work

kernel - Even more buffer cache / VM coherency work

* nvtruncbuf/nvextendbuf now clear the cached layer 2 disk offset
  from the buffer cache buffer being zero-extended or zero-truncated.
  This is required by HAMMER since HAMMER never overwrites data
  in the same media block.

* Convert HAMMER over to the new nvtruncbuf/nvextendbuf API.

  The new API automatically handles zero-truncations and zero-extensions
  within the buffer straddling the file EOF and also changes the way
  backing VM pages are handled.  Instead of cutting the VM pages off
  at the nearest boundary past file EOF any pages in the straddling
  buffer are left fully valid and intact, which avoids numerous pitfalls
  the old API had in dealing with VM page valid/dirty bits during
  file truncations and extensions.

* Make sure the PG_ZERO flag in the VM page is cleared in allocbuf().

* Refactor HAMMER's strategy code to close two small windows of
  opportunity where stale data might be read from the media.  In
  particular, refactor hammer_ip_*_bulk(), hammer_frontend_trunc*(),
  and hammer_io_direct_write().  These were detected by the fsx test
  program on a heavily paging system with physical memory set artificially
  low.

  Data flows through three stages in HAMMER:

  (1) Buffer cache.

  (2) In-memory records referencing the direct-write data offset on the
      media until the actual B-Tree is updated on-media at a later time.

  (3) Media B-Tree lookups referencing the committed data offset on the
      media.

  HAMMER must perform a careful, fragile dance to ensure that access to
  the data from userland doesn't slip through any cracks while the data
  is transitioning between stages.  Two cracks were found and fixed:

  (A) The direct-write code was allowing the BUF/BIO in the strategy
      call to complete before adding the in-memory record to the index
      for the stage 1->2 transition.  Now fixed.

  (B) The HAMMER truncation code was skipping in-memory records queued
      to the backend flusher under the assumption that the backend
      flusher would deal with them, which it will eventually, but there
      was a small window where the data was still accessible by userland
      after the truncation if userland did a truncation followed by an
      extension.  Now fixed.