Sticky sessions allow to route the same client to the same upstream server.

- upstream structures are extended to keep session-related information

- existing balancing modules are updated to provide an id of the selected
  server (SID) in pc->sid, and to select the server, given it's SID.

- other balancing modules are allowed to set the pc->hint value to choose
  the desired peer.  The sticky module will not change the hint if it's
  already set.

- the feature is enabled by default and can be disabled with the
  "--without-http_upstream_sticky" switch of the configure script.

The following configuration can be used to enable sticky sessions for
supported balancing modules:

    upstream u1 {
        server 127.0.0.1:8080;
        server 127.0.0.1:8081;

        sticky cookie server_id expires=1h domain=.example.com path=/;
    }

Co-authored-by: Ruslan Ermilov <ru@nginx.com>
Co-authored-by: Roman Arutyunyan <arut@nginx.com>
Co-authored-by: Maxim Dounin <mdounin@mdounin.ru>

Specifying the upstream server by a hostname together with the
"resolve" parameter will make the hostname to be periodically
resolved, and upstream servers added/removed as necessary.

This requires a "resolver" at the "http" configuration block.

The "resolver_timeout" parameter also affects when the failed
DNS requests will be attempted again.  Responses with NXDOMAIN
will be attempted again in 10 seconds.

Upstream has a configuration generation number that is incremented each
time servers are added/removed to the primary/backup list.  This number
is remembered by the peer.init method, and if peer.get detects a change
in configuration, it returns NGX_BUSY.

Each server has a reference counter.  It is incremented by peer.get and
decremented by peer.free.  When a server is removed, it is removed from
the list of servers and is marked as "zombie".  The memory allocated by
a zombie peer is freed only when its reference count becomes zero.

Co-authored-by: Roman Arutyunyan <arut@nginx.com>
Co-authored-by: Sergey Kandaurov <pluknet@nginx.com>
Co-authored-by: Vladimir Homutov <vl@nginx.com>

This slightly reduces cost of selecting a peer if all or almost all peers
failed, see ticket #1030.  There should be no measureable difference with
other workloads.

While this may result in non-ideal distribution of requests if nginx
won't be able to select a server in a reasonable number of attempts,
this still looks better than severe performance degradation observed
if there is no limit and there are many points configured (ticket #1030).
This is also in line with what we do for other hash balancing methods.