commit 073a1beb4a7cd709c6b1eaa56a319c1829a94d11
Author: Sean McArthur <[email protected]>
Date:   Mon Apr 29 17:54:01 2019 -0700

    tap: remove need to clone Services (#238)

    This refactors the tap system to not require intermediary channels to
    register matches and taps when a request comes through. The Dispatcher
    that used to exist in order to prevent tapping more requests than the
    limit asked for has been removed. In its place is a shared atomic
    counter to keep the count under the limit.

    The resulting behavior should be the same. There should be improved
    performance as tap registration doesn't need go through a second
    channel, and requests don't need to be delayed waiting for the
    dispatcher to be able to process its queue.

    Signed-off-by: Sean McArthur <[email protected]>

commit 7a3be8c8737188e5debbc465f9a33da0d79b8b80
Author: Zahari Dichev <[email protected]>
Date:   Wed May 1 01:57:01 2019 +0300

    Replace fixed reconnect backoff with exponential one (#237)

    When reconnecting to a destination, use an exponential, jittered backoff strategy.

    Signed-off-by: Zahari Dichev <[email protected]>

commit 32b813aad4fe2fcf0252e8c2215d6835101d2337
Author: Oliver Gould <[email protected]>
Date:   Tue Apr 30 15:58:20 2019 -0700

    Support endpoint weights (#230)

    This change modifies the proxy to honor weights provided by the
    destination service. When the destination service replies with a
    weight, this value is divided by 10,000 to produce a weight on
    [0.0, ~400000.0]. This weight is used by load the load balancer
    to modify load interpretation and therefore request distribution.

    A weight of 0.0 will cause the endpoint's load to be effectively infinite
    so that requests will only be sent to the endpoint when no other endpoints
    exists or when the other endpoints that were considered had 0-weights.

commit 501802671a346250b6dbaae73f29d9be7a4c2086
Author: Sean McArthur <[email protected]>
Date:   Wed May 1 13:42:38 2019 -0700

    Remove buffers from endpoint stacks (#239)

    Due to the `http::settings::router`, a `buffer` was needed in each
    endpoint stack. This meant that the service was always ready, even if
    the client were falling over (and reconnecting). In turn, this meant
    that the balancer would pick one of these endpoint stacks, because it
    was always ready!

    This change includes a test of a failing endpoint, that the balancer no
    longer assumes it is ready, and has the following functional changes:

    - Removed `http::settings::router`, instead the client HTTP settings are
      detected as part of the `DstAddr`. This means that each balancer only
      has endpoints with the same HTTP settings.
    - Removed `buffer` layer from inside the endpoint stacks.

    Signed-off-by: Sean McArthur <[email protected]>