hammer2 - flush sequencing part 1

* Rip out the jerry-rigged flush sequencer and start work on a real
  one.

* Sync and fsync calls create synchronization points and will be serialized
  against each other.

* Modifying operations occurring before a synchronization point will stall
  modifying operations occurring after the synchronization point until
  they complete.  This will need to be optimized.

* However, the synchronization points are coded such that modifying operations
  occurring after a synchronization point will be able to run concurrently
  with the disk flush related to that synchronization point.

  So if there is only one synchronization point (sync or fsync or background
  sync) active, modifying operations will generally not stall.  At least not
  for very long.
hammer2 - flush sequencing part 2

* API adjustments.  Add trans to setsubmod and pass &chain to
  hammer2_chain_modify() so it can (soon) modify/duplicate and
  return a different chain.

* Tentitively add flush_tid tracking to the hmp which will
  soon be used by the modify code to determine when a duplication
  is required.
Use C99 __func__ instead of __FUNCTION__.
sbp(4): Maximum I/O size is 512KB
kernel/scsi_da: Use __func__ for printing function names.
kernel/scsi_da: If booting verbosely, si_iosize_max when registering.
bnx: Utilize hardware supplied RSS hash

The IP fragments detection is done in the same fashion as:
42ad0e07a760aa29981d4650100f65e770f8f144
which may need further investigation.
Merge branch 'master' of ssh://crater.dragonflybsd.org/repository/git/dragonfly
cpdup - add -n (not-for-real) option

* Add cpdup -n, which causes cpdup to go through the motions but not
  actually make any modifications.
ahci(4): Maximum I/O size is 2MB
revert sys/dev/drm/drmP.h