Duplicate processing was possible if the address set by realip was
listed in set_realip_from, and there was an internal redirect so module
context was cleared.  This resulted in exactly the same address being set,
so this wasn't a problem before the $realip_remote_addr variable was
introduced, though now results in incorrect $realip_remote_addr being
picked.

Fix is to use ngx_http_realip_get_module_ctx() to look up module context
even if it was cleared.  Additionally, the order of checks was switched to
check the configuration first as it looks more effective.

When the last_buf flag is cleared for add_after_body to append more data from a
subrequest, other filters may still have buffered data, which should be flushed
at this point.  For example, the sub_filter may have a partial match buffered,
which will only be flushed after the subrequest is done, ending up with
interleaved data in output.

Setting last_in_chain instead of last_buf flushes the data and fixes the order
of output buffers.

The last_buf flag should only be set in the last buffer of the main request.
Otherwise, several last_buf flags can appear in output.  This can, for example,
break the chunked filter, which will include several final chunks in output.

Its usefulness it questionable, and it interacts badly with max_conns.

Previously flags passed by --with-ld-opt were not used when building perl
module, which meant hardening flags provided by package build systems were not
applied.

Previously, the realip module could be left with uninitialized context after an
error in the ngx_http_realip_set_addr() function.  That context could be later
accessed by $realip_remote_addr and $realip_remote_port variable handlers.