Read event on a client connection might have been disabled during
previous processing, and we at least need to handle events.  Calling
ngx_http_upstream_process_upgraded() is a simpliest way to do it.

Notably this change is needed for select, poll and /dev/poll event
methods.

Previous version of this patch was posted here:
http://mailman.nginx.org/pipermail/nginx/2014-January/041839.html

It simplifies the code and allows easy reuse the same queue pointer to store
streams in various queues with different requirements.  Future implementation
of SPDY/3.1 will take advantage of this quality.

The "length" value better corresponds with the specification and reduces
confusion about whether frame's header is included in "size" or not.

Also this change simplifies some parts of code, since in more cases the
length of frame is more useful than its actual size, especially considering
that the size of frame header is constant.

There is no need in separate "free" pointer and like it is for ngx_chain_t
the "next" pointer can be used.  But after this change successfully handled
frame should not be accessed, so the frame handling cycle was improved to
store pointer to the next frame before processing.

Also worth noting that initializing "free" pointer to NULL in the original
code was surplus.

Previously, only stream CANCEL and INTERNAL_ERROR were handled right.

That code was based on misunderstanding of spdy specification about
configuration applicability in the SETTINGS frames.  The original
interpretation was that configuration is assigned for the whole
SPDY connection, while it is only for the endpoint.

Moreover, the strange thing is that specification forbids multiple
entries in the SETTINGS frame with the same ID even if flags are
different.  As a result, Chrome sends two SETTINGS frames: one with
its own configuration, and another one with configuration stored
for a server (when the FLAG_SETTINGS_PERSIST_VALUE flags were used
by the server).

To simplify implementation we refuse to use the persistent settings
feature and thereby avoid all the complexity related with its proper
support.

The "headers" is not a good term, since it is used not only to count
name/value pairs in the HEADERS block but to count SETTINGS entries too.

Moreover, one name/value pair in HEADERS can contain multiple http headers
with the same name.

No functional changes.

While processing a DATA frame, the link to related stream is stored in spdy
connection object as part of connection state.  But this stream can be closed
between receiving parts of the frame.

During the processing of input some control frames can be added to the queue.
And if there were no writing streams at the moment, these control frames might
be left unsent for a long time (or even forever).

This long delay is especially critical for PING replies since a client can
consider connection as broken and then resend exactly the same request over
a new connection, which is not safe in case of non-idempotent HTTP methods.

There is no reason to allocate it from connection pool that more like just
a bug especially since ngx_http_spdy_settings_frame_handler() already uses
sc->pool to free a chain.