non buffered request: rename r->request_buffering to r->request_buffering_off

* Directives proxy_request_buffering and fastcgi_request_buffering is enabled
  by default, in which case r->request_buffering should be 1.

  If r->request_buffering is 1 by default, we should patch all subrequest
  creating functions to set this field of sub request structure.

* This commit also fixes segfault if sub requset has input body.
  If uri '/lua' is requested, tengine will segfault with following configure:
  ```
    location /memc {
        set $memc_key $echo_request_uri;
        set $memc_exptime 600;
        memc_pass 127.0.0.1:11211;
    }

    location /lua {
        content_by_lua '
            res = ngx.location.capture("/memc",
                { method = ngx.HTTP_PUT, body = "hello" });
        ';
    }
  ```
Merge pull request #539 from chobits/master

non buffered request: rename r->request_buffering to r->request_buffering_off
Setting $args now invalidates unparsed uri

* Merge nginx hg commit (changeset 5699:e9dbffc18a77)
* See http://forum.nginx.org/read.php?29,246766,246766 for details
Merge pull request #540 from chobits/master

Setting $args now invalidates unparsed uri
Disable SSLv3 from the default SSL bitmask

At this stage, there are few user agents in the wild which do not support
anything better than SSLv3. Even in China, the usual place cited for wide
deployments of Windows XP and Internet Explorer 6, the number of SSLv3-only
clients is rapidly diminishing since Windows XP is no longer receiving updates
and web designers around the world are now actively desupporting Internet
Explorer 6.

In light of the POODLE attack, and its recommended mitigation of RC4 for
client/server pairs which do not support TLS_FALLBACK_SCSV, it feels somewhat
irresponsible for a web server to default to known-vulnerable behavior. This
is especially true when enabling SSLv3 is as simple as specifying it in the
server's config file.

Besides Internet Explorer 6, embedded and mobile devices are generally the
only widely-deployed user agents which will be affected by the disabling of
SSLv3 from the default suite. In the case of embedded and mobile use, the
status quo seems to be that developers and administrators are explicit about
which options they set so that future changes in behavior will not affect
their deployments. However, it may be worth a documentation note.

Originally reported by Thomas Ward in nginx ticket 653:
http://trac.nginx.org/nginx/ticket/653

This patch has been tested against OpenSSL 0.9.7l 28 Sep 2006 as well as
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29). I do not
have any older OpenSSL versions available to me readily, and newer OpenSSL
is unlikely to have any issues whatsoever with disabling SSLv3.