tcp/tso: Add per-device TSO aggregation size limit

- Prevent possible TSO large burst, when it is inappropriate (plenty of
  >24 segements bursts were observered, even when 32 parallel sending TCP
  streams are running on the same GigE NIC).
  TSO large burst has following drawbacks on a single TX queue, even on
  the devices that are multiple TX queues capable:
  o  Delay other senders' packet transmission quite a lot.
  o  Has negative effect on TCP receivers, which sends ACKs.
  o  Cause buffer bloat in software sending queues, whose upper limit is
     based on "packet count".
  o  Packet scheduler's decision could be less effective.
  On the other hand, TSO large burst could improve CPU usage.
- Improve fairness between multiple TX queues on the devices that are
  multiple TX queues capable but only fetch data on TSO large packet
  boundary instead of TCP segment boundary.

Drivers could supply their own TSO aggregation size limit.  If driver
does not set it, the default value is 6000 (4 segments if MTU is 1500).
The default value increases CPU usage a little bit: on i7-2600 w/ HT
enabled, single TCP sending stream, CPU usage increases from 14%~17%
to 17%~20%.

User could configure TSO aggregation size limit by using ifconfig(8):
ifconfig ifaceX tsolen _n_
tcp: Improve sender-sender and sender-receiver fairness on the same netisr

Yield to other senders or receivers on the same netisr if the current TCP
stream has sent certain amount of segments (currently 4) and is going to
burst more segments.  sysctl net.inet.tcp.fairsend could be used to tune
how many segements are allowed to burst.  For TSO capable devices, their
TSO aggregate size limit could also affect the number of segments allowed
to burst.  Set net.inet.tcp.fairsend to 0 will allow single TCP stream to
burst as much as it wants (the old TCP sender's behaviour).

"Fairsend" is performed at the places that do not affect segment sending
during congestion control:
- User requested output path
- ACK input path

Measured improvement in the following setup:

+---+            +---+
|   |<-----------| B |
|   |            +---+
| A |
|   |            +---+
|   |----------->| C |
+---+            +---+

A (i7-2600, w/ HT enabled), 82571EB
B (e3-1230, w/ HT enabled), 82574L
C (e3-1230, w/ HT enabled), 82574L
The performance stats are gathered from 'systat -if 1'

When A runs 8 TCP senders to C and 8 TCP receivers from B, sending
performance are same ~975Mbps, however, the receiving performance before
this commit stumbles between 670Mbps and 850Mbps; w/ "fairsend" receiving
performance stays at 981Mbps.

When A runs 16 TCP senders to C and 16 TCP receivers from B, sending
performance are same ~975Mbps, however, the receiving performance before
this commit goes from 960Mbps to 980Mbps; w/ "fairsend" receiving
performance stays at 981Mbps stably.

When there are more senders and receivers running on A, there is no
noticable performance difference on either sending or receiving between
non-"fairsend" and "fairsend", because senders are no longer being able
to do continuous large burst.

"Fairsend" also improves Jain's fairness index between various amount of
senders (8 ~ 128) a little bit (sending only tests).