Add a sysctl "net.inet.tcp.aggregate_acks" which controls the tcp ack

Add a sysctl "net.inet.tcp.aggregate_acks" which controls the tcp ack
aggregation feature, default to on.  This feature was added a while
back and most systems will want to leave it on.  The feature only effects
situations where TCP packets are aggregated by e.g. a GigE interface or a
router talking to a GigE interface and allows the tcp stack to send just
one ack after receiving a large burst (~8-10) of tcp packets rather then
sending four or five back-to-back acks.  The single ack actually gets the
sequence space updated more quickly on the other end as well as greatly
reduces the PPS rate and bandwidth used by the return channel.  Protocol
stacks on both ends are also made more efficient due to the fewer acks that
need to be sent and received.

The feature has one side-effect which warrents having the sysctl.  The
slow-start exponential ramp-up takes longer to ramp-up due to the lower
ack rate, reducing tcp bandwidth at the beginning of the connection (but
not once it gets going).  This ONLY effects links which huge bandwidth-delay
products (like 100ms x 100MBits), and then only for a short time, and
even in such cases the difference is not usually noticeable except when
explicitly tested for.  LANs and most WAN links are NOT effected.   The
positive aspects greatly outweight the negative ones in most cases and
sysops will almost always want to leave the feature on.

Delayed-Ack-Analysis-by: Noritoshi Demizu <demizu@dd.iij4u.or.jp>