The TCP delayed ACK logic isn't aware of LRO passing up large aggregated
segments thinking it received only one segment. This causes it to enable
the delay the ACK for 100ms to wait for another segment which may never
come because all the data was received already.

Doing delayed ACK for LRO segments is bogus for two reasons: a) it pushes
us further away from acking every other packet; b) it introduces additional
delay in responding to the sender.  The latter is especially bad because it
is in the nature of LRO to aggregated all segments of a burst with no more
coming until an ACK is sent back.

Change the delayed ACK logic to detect LRO segments by being larger than
the MSS for this connection and issuing an immediate ACK for them to keep
the ACK clock ticking without interruption.

Reported by:	julian, cperciva
Tested by:	cperciva
Reviewed by:	lstewart
MFC after:	3 days
Thou shalt not leak build host state into the system being compiled.

The VERSION variable is encoded into the SUNW_ctf sections of the kernel
and every kernel module when dtrace is enabled; starting with 9.2-RELEASE
(when dtrace was turned on in GENERIC) this means that different host kernels
will result in very different kernel binaries being generated.  This tripped
up freebsd-update builds after the build boxes were updated from 9.x to 10.x.

MFC after:	3 days (stable/9)
X-MFC after:	0 days (stable/10)
Security:	Rendered two members of so@ temporarily insane
Rename the "alfred" command to "auto", and document it.  Retain support
for "portsnap alfred" for now.

Discussed:	many times, most recently on svn-src-all
MFC after:	1 week