hammer2 - Config notifications, cleanup HAMMER2 VFS API

hammer2 - Config notifications, cleanup HAMMER2 VFS API

* A hammer2 volume has a PERSISTENT table of 256 entries in the media
  volume header for specifying how the cluster connects together.  Various
  hammer2 directives can list, add, or remove entries from this table.

  This table will be used for several different aspects of the filesystem
  and one of them is to tell the userland hammer2 service daemon what
  other machines to connect to.  That is, we want the cluster configuration
  to be persistently stored as part of a HAMMER2 filesystem.

* Add a notification message from the kernel to the daemon whenever this
  table id modified.  The kernel will also spam the contents of the table
  to the daemon when it first connects to the daemon.

  The service daemon tracks the table and will connect to (or disconnect
  from) the listed targets in real time.  In addition, the service daemon
  will retry a failed connection (or failed DNS lookup) forever as long
  as the entry is intact.  The idea being that a machine in the cluster
  will recover once transitory failures are resolved.

  This is a bit messy at the moment as two pthreads have to be created for
  each connection... one to handle connect, disconnect, and retry operations
  and the other to handle the actual message stream over the connection.

* Clean up the HAMMER2 VFS code's messaging APIs a bit, bringing them
  closer to the hammer2 userland APIs (though of course there will
  always be major differences).

* Adjust the hammer2 VFS to try to clean up open transactional states
  when a socket failure occurs before proceeding with a umount, so the
  related functional states can be triggered and cleaned up.

* Added an ioctl to reconnect a hammer2 mount to the userland hammer2
  service daemon (not yet used).  This will allow us to kill and restart
  the daemon and have it recover the communications pipes between itself
  and the HAMMER2 mounts in the kernel.