When secure link checksum has length of 23 or 24 bytes, decoded base64 value
could occupy 17 or 18 bytes which is more than 16 bytes previously allocated
for it on stack.  The buffer overflow does not have any security implications
since only one local variable was corrupted and this variable was not used in
this case.

The fix is to increase buffer size up to 18 bytes.  Useless buffer size
initialization is removed as well.

This variable contains URL-encoded client SSL certificate.  In contrast
to $ssl_client_cert, it doesn't depend on deprecated header continuation.
The NGX_ESCAPE_URI_COMPONENT variant of encoding is used, so the resulting
variable can be safely used not only in headers, but also as a request
argument.

The $ssl_client_cert variable should be considered deprecated now.
The $ssl_client_raw_cert variable will be eventually renambed back
to $ssl_client_cert.

Total length of a response with multiple ranges can be larger than a size_t
variable can hold, so type changed to off_t.  Previously, an incorrect
Content-Length was returned when requesting more than 4G of ranges from
a large enough file on a 32-bit system.

An additional size_t variable introduced to calculate size of the boundary
header buffer, as off_t is not needed here and will require type casts on
win32.

Reported by Shuxin Yang,
http://mailman.nginx.org/pipermail/nginx/2017-July/054384.html.

Pass NGX_FILE_OPEN to ngx_open_file() to fix "The parameter is incorrect"
error on win32 when using the ssl_session_ticket_key directive or loading
a binary geo base.  On UNIX, this change is a no-op.

This, in addition to 1eb753aa8e5e, fixes "upstream zone" on Windows.

The variable was considered non-existent in the absence of any
valid_referers directives.

Given the following config snippet,

    location / {
        return 200 $invalid_referer;
    }

    location /referer {
        valid_referers server_names;
    }

"location /" should work identically and independently on other
"location /referer".

The fix is to always add the $invalid_referer variable as long
as the module is compiled in, as is done by other modules.

The shared objects should generally be allocated from shared memory.
While peers->name and the data it points to allocated from cf->pool
happened to work on UNIX, it broke on Windows.  On UNIX this worked
only because the shared memory zone for upstreams is re-created for
every new configuration.

But on Windows, a worker process does not inherit the address space
of the master process, so the peers->name pointed to data allocated
from cf->pool by the master process, and was invalid.

No functional changes.