[split] A bit of cleanup in finagle-serversets.

A few (largely cosmetic) aspects of the file ServerSet2.scala are
reworked:

- The hierarchy of implementations of the ServerSet2 trait is
  flattened. The reasoning for this is that it simplifies the interface
  one uses to construct ServerSet2 instances. Rather than a mismatched
  variety of constructors and factory functions, you simply pass a
  `Var[Zk]` to the ServerSet2 constructor. This has the downside of
  foundering the separation of concerns of Var and Zk from the
  ServerSet2 trait, which arguably goes against the desire to separate
  the service discovery library from ZooKeeper. However, I think that an
  easier-to-reason-about ServerSet2 class outweighs the benefits of
  wholly separating each of these concepts. Especially given plans for
  follow-on passes over this code to factor out the ZK bits.

- com.twitter.util.Memoize is used to remove the need for a `var` to
  cache ServerSet2 instances

- More documentation is added, specifically the help message of the
  `com.twitter.newZk` flag and a number of public APIs' Scaladocs

RB_ID=481107
[split] Introduce Balancer

Problem

Working with P2C was becoming unwieldy. It does not separate concerns
very well.

Solution

Split up the responsibilities of balancing, updating, node
maintenance, and state maintenance.

RB_ID=471979
[split] finagle-serversets: memoize parsed HostPorts in serverset2

RB_ID=489325
[split] finagle-core: improve documentation for RetryPolicy.tries

Problem

A lack of documentation on `RetryPolicy.tries` leaves the
exercise to readers.

Solution

Improve the documentation and fix some minor broken windows.

RB_ID=488821
[split] finagle-serversets: Remove per-path histograms

Problem

finagle-serversets currently emits four histograms for each path that
it's asked to look up. For services that resolve large numbers of
serversets (namely TFE and the Wily Nameserver), this explodes into
thousands of metrics. There are no known usages of these stats for
monitoring purposes, so it's a huge waste and memory pressure burden.

Solution

Remove the per-path histograms in favor of four aggregated read- and
parse-latency histograms for entries and vectors.

Result

The number of stats emitted under the "zk2" scope is vastly
reduced. The per-path "size" and "limbo" stats are maintained, as are
those emitted by the InetResolver that is embedded within the
Zk2Resolver.

RB_ID=484443
[split] Fix incorrectly written test in finagle-kestrel - Fix incorrectly written test in finagle-kestrel   Problem:   finagle-kestrel test in MultiReaderTest fails because the empirically   determined order of messages is not always true.

  Solution:
  Keep track of the messages in a Set instead of assuming any specific
  order.

  Result:
  Test passes.

RB_ID=488487
[split] Revert "CSL-1191 - flaky: com.twitter.finagle.stats.StatsReceiverTest.rollup statsReceiver work in action"

RB_ID=490665
[split] finagle-core: Add balancer factory for ewma

Problem

We need a way to inject the ewma load metric per client.

Solution

Create a WeightedLoadBalancerFactory that instantiates a
P2CBalancerPeakEwma. This now allows us to inject it via
LoadBalancerFactory.Param (and ClientBuilder).

RB_ID=490021
[split] ChannelException should also wire service name to its string representation

RB_ID=487297
[split] finagle-core: Liberate Transporter and Listener params

RB_ID=491365
[split] Enable com.twitter.newZk by default.

RB_ID=491401
[split] finagle-core: Fixes TimeoutAndWriteExceptionsOnly RetryPolicy

Problem

Services that are configured with TimeoutAndWriteExceptionsOnly
expect to retry on request timeouts, but don't.

Solution

Change RetryPolicy behavior to retry on request timeouts properly.

RB_ID=491721
[split] finagle: fix BUILD dependencies

RB_ID=491711
[split] bump util to 6.22.2-SNAPSHOT

RB_ID=493423
TBR=true
NO-QUEUE=true
[split] bump ostrich to 9.6.2-SNAPSHOT

RB_ID=493469
TBR=true
NO-QUEUE=true
[split] finagle Balancer: fix unintentional close recursion

RB_ID=493887
TBR=true
NO-QUEUE=true
[split] finagle-core: Introduce a 'parameter' field in Stack.Head

Problem

Stacks are inherently stateless and thus shared between
finagle clients and servers. The way we inferred the
parameters that a module used to configure itself
attached state to a Stack and violated this guarantee.

Solution

Introduce a `parameters` field in Stack.Head which servers
as documentation and can be dynamically introspected to
determine the fields and values that a module is interested
in. To make it easy to do the right thing, abstract definitions
for `Stackables` now take type parameters that map to the
parameters a module is interested in.

Result

We can now collect interests per-module:

val stk = ...
val params = ...

val parameters = for {
 n <- stk.tails
 interest <- n.head.parameters
} yield params(interest)

RB_ID=484747
[split] finagle-stats: mark test as flakey

https://jira.twitter.biz/browse/CSL-1209

RB_ID=493787
[split] {finagle,util}-core: Slurry of PartialFunction micro-optimizations

Problem

PartialFunction has an isDefinedAt which must be called before
proper invocation.  However, PartialFunction#isDefinedAt and
PartialFunction#apply often entail many of the same costs (ie object
allocation due to unapply for literal PartialFunctions).

Solution

PartialFunction has a helper PartialFunction#applyOrElse so that
we only have to call it once.  However, applyOrElse takes a function,
so we must make singleton all-purpose functions to avoid extra
allocations.

Result

PartialFunction evaluation is cheaper.

RB_ID=492081
[split] Introduce TwitterRPC

TwitterRPC is a library for constructing RPC clients and servers. Its
APIs facilitate high-level interprocess communication based on
objectives which are used to ensure timely service and resiliency.

By providing a narrow surface area of configuration, TwitterRPC aims
to remove much of the configuration burden from service owners and to
simplify application code. It does so via service level objectives
[1], which allow applications to define their expectations in
high-level terms without having to fret about specific
technology-dependent configuration parameters.

See [2] for more information.

[1] http://en.wikipedia.org/wiki/Service_level_objective
[2] http://go/twitterrpc

RB_ID=454939