hammer2 - Retool dmsg mechanics to improve virtual circuit design 2/2

* Use transaction stacking to effectively connect resources to consumers.
  Issuing a transaction over a received SPAN effectively creates a virtual
  circuit to the originator.

* The hammer2 service demon (userland) is currently being used to route,
  but direct kernel<->kernel socket connections are now theoretically
  possible for later performance work.  Current performance is going
  to be low due to layering.

* Get subr_diskiocom and the xdisk driver mostly working again.  The
  code is a lot cleaner but still needs considerable stability work and
  better unwinding during failure conditions.

* Start work on hammer2<->hammer2 communications.
hammer2 - dmsg stabilization

This is a general stabilization pass testing xdisk resumption on various
communications failures (killing the local or remote hammer2 service demon).

* Simulate failures on recursive transactions in a bottom-up fashion

* bcmp() does not return an inequality (neg, zero, or positive).  It
  returns only 0 or 1.  Change fs_label RBTREE test to strcmp()

* ref-count the state structure, use dmsg_state_hold()/dmsg_state_drop()
  to control it.  Fix at least one memory leak.

* Consolidate simulated transaction failure core into a helper
  function dmsg_msg_simulate_failure().

* Clean up the tx state on the front-end after the msg has extracted
  necessary information from it, instead of in the transmit thread.
  This is so the state fields are updated synchronously and not delayed
  by the transmit queue.

* Change xdisk's error test to avoid accidently failing a BIO due to
  a communications issue (verses an actual IO error on the remote physical
  disk).

* Remove some invalid assertions, add assertions.