Version bump.
Merge of r4611, r4620: resolver fixes.

*) Fixed segmentation fault in ngx_resolver_create_name_query().

   If name passed for resolution was { 0, NULL } (e.g. as a result
   of name server returning CNAME pointing to ".") pointer wrapped
   to (void *) -1 resulting in segmentation fault on an attempt to
   dereference it.

   Reported by Lanshun Zhou.

*) Resolver: protection from duplicate responses.

   If we already had CNAME in resolver node (i.e. rn->cnlen and rn->u.cname
   set), and got additional response with A record, it resulted in rn->cnlen
   set and rn->u.cname overwritten by rn->u.addr (or rn->u.addrs), causing
   segmentation fault later in ngx_resolver_free_node() on an attempt to free
   overwritten rn->u.cname.  The opposite (i.e. CNAME got after A) might cause
   similar problems as well.
Merge of r4612: proper subrequest handling in various modules.
Merge of r4613: removed surplus condition.
Merge of r4615: write handler reset in ngx_http_named_location().

On internal redirects this happens via ngx_http_handler() call, which is
not called on named location redirect.  As a result incorrect write handler
remained (if previously set) and this might cause incorrect behaviour (likely
request hang).

Patch by Yichun Zhang (agentzh).
Merge of r4616: r->state fix.

Added r->state reset on fastcgi/scgi/uwsgi request start.

Failing to do so results in problems if 400 or 414 requests are
redirected to fastcgi/scgi/uwsgi upstream, as well as after invalid
headers got from upstream.  This was already fixed for proxy in r3478,
but fastcgi (the only affected protocol at that time) was missed.

Reported by Matthieu Tourne.
Merge of r4617: fastcgi padding fix.

Fastcgi: fixed padding handling on fixed-size records.

Padding was incorrectly ignored on end request, empty stdout and stderr
fastcgi records.  This resulted in protocol desynchronization if fastcgi
application used these records with padding for some reason.

Reported by Ilia Vinokurov.
Merge of r4618: rewrite escaping fix (ticket #162).

The following code resulted in incorrect escaping of uri and possible
segfault:

    location / {
        rewrite ^(.*) $1?c=$1;
        return 200 "$uri";
    }

If there were arguments in a rewrite's replacement string, and length was
actually calculated (due to duplicate captures as in the example above,
or variables present), the is_args flag was set and incorrectly copied
after length calculation.  This resulted in escaping applied to the uri part
of the replacement, resulting in incorrect escaping.  Additionally, buffer
was allocated without escaping expected, thus this also resulted in buffer
overrun and possible segfault.
Merge of r4619: accept moderation on EMFILE/ENFILE.

In case of EMFILE/ENFILE returned from accept() we disable accept events,
and (in case of no accept mutex used) arm timer to re-enable them later.
With accept mutex we just drop it, and rely on normal accept mutex handling
to re-enable accept events once it's acquired again.

As we now handle errors in question, logging level was changed to "crit"
(instead of "alert" used for unknown errors).

Note: the code might call ngx_enable_accept_events() multiple times if
there are many listen sockets.  The ngx_enable_accept_events() function was
modified to check if connection is already active (via c->read->active) and
skip it then, thus making multiple calls safe.
Merge of r4621, r4641: filter_finalize fixes.

*) Fixed possible request hang with filter finalization.

   With r->filter_finalize set the ngx_http_finalize_connection() wasn't
   called from ngx_http_finalize_request() called with NGX_OK, resulting in
   r->main->count not being decremented, thus causing request hang in some
   rare situations.

   Patch by Yichun Zhang (agentzh).

*) Fixed segfault with filter_finalize introduced in r4621 (1.3.0).

See the following thread for more details:
http://mailman.nginx.org/pipermail/nginx-devel/2012-May/002190.html
Merge of r4622, r4623: balancing changes.

*) Upstream: smooth weighted round-robin balancing.

   For edge case weights like { 5, 1, 1 } we now produce { a, a, b, a, c, a, a }
   sequence instead of { c, b, a, a, a, a, a } produced previously.

   Algorithm is as follows: on each peer selection we increase current_weight
   of each eligible peer by its weight, select peer with greatest current_weight
   and reduce its current_weight by total number of weight points distributed
   among peers.

   In case of { 5, 1, 1 } weights this gives the following sequence of
   current_weight's:

        a  b  c
        0  0  0  (initial state)

        5  1  1  (a selected)
       -2  1  1

        3  2  2  (a selected)
       -4  2  2

        1  3  3  (b selected)
        1 -4  3

        6 -3  4  (a selected)
       -1 -3  4

        4 -2  5  (c selected)
        4 -2 -2

        9 -1 -1  (a selected)
        2 -1 -1

        7  0  0  (a selected)
        0  0  0

   To preserve weight reduction in case of failures the effective_weight
   variable was introduced, which usually matches peer's weight, but is
   reduced temporarily on peer failures.

   This change also fixes loop with backup servers and proxy_next_upstream
   http_404 (ticket #47), and skipping alive upstreams in some cases if there
   are multiple dead ones (ticket #64).

*) Upstream: fixed ip_hash rebalancing with the "down" flag.
     
   Due to weight being set to 0 for down peers, order of peers after sorting
   wasn't the same as without the "down" flag (with down peers at the end),
   resulting in client rebalancing for clients on other servers.  The only
   rebalancing which should happen after adding "down" to a server is one
   for clients on the server.

   The problem was introduced in r1377 (which fixed endless loop by setting
   weight to 0 for down servers).  The loop is no longer possible with new
   smooth algorithm, so preserving original weight is safe.
Merge of r4614, r4624-r4629, r4631: proxy recursive changes.
   
*) Added IPv6 and UNIX-domain socket support in "debug_connection"
   directive.
   
*) New function ngx_http_get_forwarded_addr() to look up real client
   address.

   On input it takes an original address, string in the X-Forwarded-For format
   and its length, list of trusted proxies, and a flag indicating to perform
   the recursive search.  On output it returns NGX_OK and the "deepest" valid
   address in a chain, or NGX_DECLINED.  It supports AF_INET and AF_INET6.
   Additionally, original address and/or proxy may be specified as AF_UNIX.
   
*) Realip: chains of trusted proxies and IPv6 support.
   
   The module now supports recursive search of client address through
   the chain of trusted proxies, controlled by the "real_ip_recursive"
   directive (closes #2).  It also gets full IPv6 support (closes #44)
   and canonical value of the $client_addr variable on address change.
        
   Example:

       real_ip_header X-Forwarded-For;   
       set_real_ip_from 127.0.0.0/8;
       set_real_ip_from ::1;
       set_real_ip_from unix:;
       real_ip_recursive on;

*) Geo: chains of trusted proxies and partial IPv6 support.

   The module now supports recursive search of client address through
   the chain of trusted proxies, controlled by the "proxy_recursive"
   directive in the "geo" block.  It also gets partial IPv6 support:
   now proxies may be specified with IPv6 addresses.

   Example:

       geo $test {
           ...
           proxy 127.0.0.1;
           proxy ::1;
           proxy_recursive;
       }

   There's also a slight change in behavior.  When original client
   address (as specified by the "geo" directive) is one of the
   trusted proxies, and the value of the X-Forwarded-For request
   header cannot not be parsed as a valid address, an original client
   address will be used for lookup.  Previously, 255.255.255.255 was
   used in this case.

*) Geoip: trusted proxies support and partial IPv6 support.

   The module now supports recursive search of client address through the
   chain of trusted proxies (closes #100), in the same scope as the geo
   module.  Proxies are listed by the "geoip_proxy" directive, recursive
   search is enabled by the "geoip_proxy_recursive" directive.  IPv6 is
   partially supported: proxies may be specified with IPv6 addresses.

   Example:

        geoip_country .../GeoIP.dat;
        geoip_proxy 127.0.0.1;
        geoip_proxy ::1;
        geoip_proxy 10.0.0.0/8;
        geoip_proxy_recursive on;