[tcp] Update window even if ACK does not acknowledge new data

iPXE currently ignores ACKs which do not acknowledge any new data.
(In particular, it does not stop the retransmission timer; this is
done to prevent an immediate retransmission if a duplicate ACK is
received while the transmit queue is non-empty.)

If a peer provides a window size of zero and later sends a duplicate
ACK to update the window size, this update will therefore be ignored
and iPXE will never be able to transmit data.

Fix by updating the window size even for ACKs which do not acknowledge
new data.

Reported-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[linux] Avoid starting currticks() from zero every time

iPXE uses currticks() (along with the MAC address(es) of any network
devices) to seed the (non-cryptographic) random number generator.  The
current implementation of linux_currticks() ensures that the first
call to currticks() will always return zero; this results in identical
random number sequences on each run of iPXE on a given machine.  This
can cause odd-looking behaviour due to e.g. the reuse of local TCP
port numbers.

Fix by effectively rounding down the start time recorded by
linux_currticks() to the nearest whole second; this makes it unlikely
that consecutive runs of iPXE will use the exact same RNG sequence.

(Note that none of this affects the cryptographic RNG, which uses
/dev/random as a source of entropy.)

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[http] Use a retry timer to trigger retried requests

Use a retry timer to allow for the possibility of deferring a retried
request.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[http] Automatically retry request on a 503 Service Unavailable

A web server may return a 503 Service Unavailable response along with
a Retry-After header to direct the client to retry the request at a
later time.

The Retry-After header may be a number of seconds, or a full HTTP
timestamp (e.g. "Fri, 7 Mar 2014 17:22:14 GMT").  We have no
reasonable way of parsing a full HTTP timestamp; if the server chooses
to use this format then we simply retry after a fixed 5-second delay.

As per RFC 2616, in the absence of a Retry-After header we treat a
status code of 503 Service Unavailable as being equivalent to 500
Internal Server Error, and immediately fail the request.

Requested-by: Suresh Sundriyal <ssundriy@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>