Negative times can appear since workers only update time on an event
loop iteration start.  If a worker was blocked for a long time during
an event loop iteration, it is possible that another worker already
updated the time stored in the node.  As such, time since last update
of the node (ms) will be negative.

Previous code used ngx_abs(ms) in the calculations.  That is, negative
times were effectively treated as positive ones.  As a result, it was
not possible to maintain high request rates, where the same node can be
updated multiple times from during an event loop iteration.
In particular, this affected setups with many SSL handshakes, see
http://mailman.nginx.org/pipermail/nginx/2018-May/056291.html.

Fix is to only update the last update time stored in the node if the
new time is larger than previously stored one.  If a future time is
stored in the node, we preserve this time as is.

To prevent breaking things on platforms without monotonic time available
if system time is updated backwards, a safety limit of 60 seconds is
used.  If the time stored in the node is more than 60 seconds in the future,
we assume that the time was changed backwards and update lr->last
to the current time.

Cast to intermediate "void *" to lose compiler knowledge about the original
type and pass the warning.  This is not a real fix but rather a workaround.

Found by gcc8.

In mail and stream modules, no certificate provided is a fatal condition,
much like with the "ssl" and "starttls" directives.

In http, "listen ... ssl" can be used in a non-default server without
certificates as long as there is a certificate in the default one, so
missing certificate is only fatal for default servers.

Previously, result of ngx_atoi() was assigned to an ngx_uint_t variable,
and errors reported by ngx_atoi() became positive, so the following check
in "status < 100" failed to catch them.  This resulted in the configurations
like "proxy_cache_valid 2xx 30s" being accepted as correct, while they
in fact do nothing.  Changing type to ngx_int_t fixes this, and such
configurations are now properly rejected.

Previously, ngx_http_upstream_process_header() might be called after
we've finished reading response headers and switched to a different read
event handler, leading to errors with gRPC proxying.  Additionally,
the u->conf->read_timeout timer might be re-armed during reading response
headers (while this is expected to be a single timeout on reading
the whole response header).

Previously, ngx_http_upstream_test_next() used an outdated condition on
whether it will be possible to switch to a different server or not.  It
did not take into account restrictions on non-idempotent requests, requests
with non-buffered request body, and the next upstream timeout.

For such requests, switching to the next upstream server was rejected
later in ngx_http_upstream_next(), resulting in nginx own error page
being returned instead of the original upstream response.

All cases are harmless and should not happen on valid values, though can
result in bad values being shown incorrectly in logs.

Found by Coverity (CID 1430311, 1430312, 1430313).

Previously, frame state wasn't saved if HEADERS frame payload
that begins with header fragment was not received at once.