Similar to map's volatile parameter, creates a non-cacheable geo variable.

Previously, it could result when left-shifting signed integer due to implicit
integer promotion, such that the most significant bit appeared on the sign bit.

In practice, though, this results in the same left value as with an explicit
cast, at least on known compilers, such as GCC and Clang.  The reason is that
in_addr_t, which is equivalent to uint32_t and same as "unsigned int" in ILP32
and LP64 data type models, has the same type width as the intermediate after
integer promotion, so there's no side effects such as sign-extension.  This
explains why adding an explicit cast does not change object files in practice.

Found with UndefinedBehaviorSanitizer (shift).

Based on a patch by Piotr Sikora.

While copying ngx_http_variable_value_t structures to geo binary base
in ngx_http_geo_copy_values(), and similarly in the stream module,
uninitialized parts of these structures are copied as well.  These
include the "escape" field and possible holes.  Calculating crc32 of
this data triggers uninitialized memory access.

Found with MemorySanitizer.

Signed-off-by: Piotr Sikora <piotr@aviatrix.com>

Previously, AF_UNIX client addresses were handled as AF_INET, leading
to unexpected results.

If the geo block parser has failed, doing more things is pointless.

If during configuration parsing of the geo directive the memory
allocation has failed, pool used to parse configuration inside
the block, and sometimes the temporary pool were not destroyed.

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.

geo $geo {
    ranges;

    10.0.0.0-10.0.0.255 test;

    delete 10.0.1.0-10.0.1.255;     # should warn

    delete 10.0.0.0-10.0.0.255;
    delete 10.0.0.0-10.0.0.255;     # should warn
}