kernel - network adjustments (netisr, tcp, and socket buffer changes)

* Change sowakeup() to use an atomic fetch when testing WAIT/WAKEUP for
  a quick return.  It is now coded properly.  Previous coding is not known
  to have created any bugs.

* Change sowakeup() to use ssb_space_prealloc() instead of ssb_space()
  when testing against the transmit low-water mark.  This is a bug fix
  which primarily effects very tiny write()'s.  The prior code is not
  known to have created any problems.

* Make the netisr packet counter before doing a rollup programmer and
  change the default from 512 to 32 for the moment.  This may be changed
  back to 512 (or some number inbetween) after further testing.

  The issue here is that interrupt/netisr pipelining can cause ack aggregation
  to be delayed for too many packets.

* For TCP, when timestamps are not being used, pass the correct delta
  to tcp_xmit_timer() in our fallback.  The function expects N+1.  This
  should improve/fix incorrect rtt calculations when tcp timestamps are
  not in use.

* Fix an edge case in tcp_xmit_bandwidth_limit() where the 'ticks' global
  could change values out from under the code.  Load the global into a local
  variable.

* Change the inflight code to use (t_srtt + t_rttvar) instead of
  (t_srtt + t_rttbest) / 2.

  This needs fine-tuning, the buffer is still too big.  Expect more commits
  later.

* Call sowwakeup() when appending a mbuf to a stream.  The append can call
  sbcompress() and make a stream buffer that has hit its mbuf limit writable
  again.

* Remove the ssb_notify() macro and collapse the sorwakeup() and sowwakeup()
  macros.  They now just call sowakeup() on the appropriate sockbuf.  The
  notify test is now done in sowakeup().
tcp: Set upper limit for the DupThresh generated by the NCR

The DupThresh could be pretty large due to large amount of outstanding
segments on the fast local area network.  If the reception side really
lost some segments, the fast recovery would be delayed for a long time.
It would become even worse, if the reception side aggregated ACKs, i.e.
widely used LRO; it could even cause timeout retransmition, which is
highly unappreciated on the fast local area network.  Put an upper
limit for the DupThresh, currently 16, so that fast recovery could take
over segment retransmittion in a timely fashion.  The upper limit of
DupThresh could be controlled by sysctl net.inet.tcp.ncr_rxtthresh_max.