HAMMER VFS - Fix probable corruption case when filesystem becomes nearly full

HAMMER VFS - Fix probable corruption case when filesystem becomes nearly full

* The reblocking code was incorrectly assuming the cursor would be pointing
  at a valid node element after an unlock/relock sequence, when it could
  actually be pointing at the EOF of a node.  This case can occur when
  the filesystem is nearly full (possibly due to the reblocking operation
  itself), when the filesystem is also under load from unrelated
  operations.

* This can result in the creation of a corrupted B-Tree leaf node or
  data record.

* Corruption can be checked with hammer checkmap and hammer show
  (as of this rev):

  hammer -f device checkmap

	Should output no B-Tree node records or free space mismatches.
	You will still get the initial volume summary.

  hammer -f device show | egrep '^B' | egrep -v '^BM'

	Should output no records.

* Currently the only recourse if corruption is found is to copy off the
  filesystem, newfs_hammer, and copy it back.

  Full history and snapshots can be retained by using 'hammer -B mirror-read'
  to copy off the filesystem and mirror-write to copy it back.  However,
  pleaes remember you must do this for each PFS individually.  Make sure
  you have a viable backup before newfsing anything.

Reported-by: Francois Tigeot <ftigeot@wolfpond.org>, Jan Lentfer <Jan.Lentfer@web.de>