[split] s/GUILD/CSL/ for all CONFIG.ini's

RB_ID=378107
TBR=true
[split] birdcage: Extract and unify inline jar dependencies where possible

This review removes inline jar() definitions from (java|scala)_library() definitions. It attempts to move the dependencies to 3rdparty subdirectories wherever possible, and propagate OWNERSship from the dependent projects.

In many cases, versions could not be trivially unified, and TODOs were inserted with associated tickets.

- Removes inline jar() definitions from (java|scala)_library() definitions
- Updates querulous for latest commons-pool
- Fixes libthrift exclusions to obviate inline `libthrift` force=True definitions
- Unifies 3rdparty `bijection`/`scalding`/`summingbird` definitions to relevant subdirectories
- Prunes unused 3rdparty targets

RB_ID=374900
TBR=true
[split] Move Flock/TFlock to finagle-serversets

This rb introduces finagle-serverset to Flock and TFlock. It also upgrades all gizzard services (and any other service depending on scribe_client in 3rdparty) to the birdcage version of finagle.

RB_ID=361215
[split] finagle-core: Added a service acquisition latency stat to StatsFactoryWrapper

Problem

If someone's service is queueing, it's difficult to tell if it's
actually causing a problem.  This change makes it much easier to
tell.

Result

We can tell directly if service acquisition is slow without relying
upon proxy metrics.

RB_ID=373428
[split] Problem

finagle-redis lacks support for the 'DUMP' command.

Solution

Implement the 'DUMP' command.

Signed-off-by: Steve Gury <stevegury@twitter.com>

RB_ID=379233
[split] Add Google Analytics tracking code

Signed-off-by: Travis Brown <tbrown@twitter.com>

RB_ID=378845
[split] finagle-mux: Unflakied some tests

Problem

There were some flaky tests in finagle-mux

Result

No more races in the finagle-mux tests

RB_ID=377917
[split] Finagle-stats: add ability to filter stats out

Problem:

Metrics are expensive to store in Observability. Not every metric is needed: some metrics aren't needed after the incident remediations were put in place, other metrics are feature flags. Ostrich already has the functionality to do runtime filtering of metrics according to a preconfigured blacklist of regexes (see https://confluence.twitter.biz/display/OBSERVE/Filtering+out+the+stats). This means that by passing "filtered=1", it can filter out a subset of metrics, whereas without this parameter, all metrics would be returned.

It's also unfeasible to store the blacklists on Observability side for two reasons:
- the configuration management for metrics left out should inherently belong to the service owners; this means that they can easily add/remove these filters and are in full control of them
- the longer the metrics 'travel', the higher the cost. Ideally, we'd like to filter these out at the origin, that is, the service that exports them

Why not remove all unnecessary metrics from the code? There are several reasons:
- they may be used in the future and are a part of the instrumentation
- they may be useful in per-host debugging or using CuckooShrike, but not needed in Observability stack due to their high cost.

Solution:

Add the same filtering logic to finagle-stats, with similar API. Due to a lack of direct integration between Twitter-Server and finagle-stats, use a GlobalFlag.

Results and next steps:

Example: java MyServer -com.twitter.finagle.stats.statsFilter="jvm.*,incr_time.p99*"
curl -s "localhost:9990/admin/metrics.json?filtered=1"

The ability to filter out the metrics. Next steps are working with service owners to enable these filters for metrics that they never use. Hummingbird collector and Absorber can then pass "filtered=1" to Metrics when querying for stats.

RB_ID=378815
TBR=true
[split]  finagle-core: Adds a Flag to turn on per host stats

 Problem
 Want the ability to enable/disable per-host stats

 Solution

 Per-host stats can now be enabled via the command line flag:
 com.twitter.finagle.loadbalancer.perHostStats=true

 When enabled, the configured stats receiver for each client is used, or the
 loadedStatsReceiver if none is configured (Note that if the configured stats
 receiver is a NullStatsReceiver, a NullStatsReceiver will be used. This way,
 per-host stats can be enabled on a per-client basis).

 When disabled (default state), the per-host stats receiver is the configured
 stats receiver, or the NullStatsReceiver if none is configured.

 Result

 Services currently exporting per-host stats will continue to export per-host
 stats. Those that do not will continue to not export per-host stats.

 To enable per-host stats with the loaded stats receiver:
 - Do not configure the per-host stats receiver and re-start the service
   with -com.twitter.finagle.loadbalancer.perHostStats

 To enable per-host stats with a specific stats receiver:
 - Configure the per-host stats receiver with a non-null stats receiver
   and re-start the service

 To disable per-host stats:
 - Do not configure the per-host stats receiver and re-start the service
   with com.twitter.finagle.loadbalancer.perHostStats=false

RB_ID=375868
[split] zk2: Start resolution eagerly

Problem

Some services have come to rely on the eager serverset resolution
semantics presented by zk1, since this allows resolution to proceed
concurrently with program startup. While this is racy behavior --
finicky, at best, to rely on -- these are nonetheless the facts on the
ground.

Solution

Start resolving zk2 serversets eagerly. A better longer-term solution
is to have some sort of API to indicate client readiness so that
services may instead rely on this.

RB_ID=376325
[split] finagle-core: Use Monitor from caller's context in DefaultTimer

Problem

There is currently no way to recover from exceptions thrown in com.twitter.finagle.util.DefaultTimer.twitter's schedule methods.

Solution

Use the Monitor in the context of the caller of schedule methods to handle exceptions in com.twitter.finagle.util.TimerFromNettyTimer, and by extension, DefaultTimer.twitter.

Result

One can now wrap Monitor#apply calls around DefaultTimer.twitter.{schedule,doLater,doAt} methods to use the monitor in current context:

    val monitor: Monitor = ...
    monitor { timer.doLater(5.seconds) { stuff } }

RB_ID=379225
[split] Marked thrift tmux end-to-end tests as flaky

RB_ID=381679
TBR=true
[split] finagle-kestrel: Add Name-based methods for MultiReader construction

Problem

finagle-kestrel currently only offers APIs for constructing
MultiReader client instances based on Var[Addr]. This forces consumers
to make the leap from Name instances returned by `Resolver.eval` to
Var[Addr]. This is very error-prone and would inevitably lead to the
proliferation of converter code in every service that uses
finagle-kestrel.

Solution

Add two apply methods to both MultiReaderMemcache and
MultiReaderThrift that take Name arguments. This centralizes the
Name.Bound decomposition in library code where it belongs.

Note that I chose to not support Name.Path in these new
methods. finagle-kestrel deviates fairly heavily from the Finagle
"client stack" model, including having no adherence to Dtabs. Rather
than make a hacky attempt to resolve Name.Path, these new `apply`
methods only support Name.Bound, falling back on Addr.Neg and logging
a warning message on Name.Path.

RB_ID=376835
[split] com.twitter.finagle.Path: don't support empty path elements

These complicate the grammar and makes it difficult to represent the
path "/" accurately. The only place I could these in use was for inet
address like

	/$/inet//8080

this is equivalent to

	/$/inet/0/8080

since Java's InetSocketAddress interpretes an empty host argument as
the Internet address 0.

RB_ID=381909
[split] Move API error codes out of the monorail.

RB_ID=369980
[split] finagle-mux: GC Avoidance Algorithm

Problem

In order to choose when we do GC avoidance, we need to guess in
advance when the JVM will do GC automatically, and respond properly.
As a first-order heuristic, we're going to use an exponential
weighted moving average.

Solution

We wrote a jvm GC heuristic for finagle, and use it to decide when
to drain.  After we've drained, we try to force a minor gc, and
then undrain.

Result

We have all of the pieces in place to detect how to set our leases
properly.

RB_ID=371522
[split] finagle-core: Makes c.t.f.Failure a direct subclass of Exception

Problem

c.t.f.Failure is currently a subtype of RuntimeException.  However,
RuntimeExceptions should be used to represent the result of a
programming problem[0] in finagle--most Failures in finagle will
instead represent things that happen in the normal usage of finagle.
For users that respond appropriately to RuntimeExceptions (for
example by crashing) they will be surprised to get many RuntimeExceptions
per second in the normal operation of their service.

[0]: http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Result

c.t.f.Failure now extends Exception, instead of RuntimeException

RB_ID=371936
[split] skip SOCKS proxy when connecting to loopback addresses

Problem:
When using finagle over SOCKS proxy, the current implementation
attempts to connect to every destination inet address via the proxy,
including local loopback addresses.

This is problematic since it fails to connect to a service that might
be running on the developer laptop (ex: local memcached or service
tunnel).

Solution:
Easily fixed by skipping `SocksConnectHandler` if the destination
inet address is the loopback address.

Result:
After this change, connecting to attempts to localhost will not go
through the SOCKS proxy handler, resulting in successful connections
to locally established tunnels and services.

RB_ID=383169
[split] finagle-mux: Moved UseMux to the correct directory

Problem

finagle-mux didn't compile because UseMux was in the wrong directory

Result

finagle-mux compiles

RB_ID=383585
TBR=true
[split] finagle-memcached: Expose the client type `KetamaClient` in the build() API

Problem

KetamaClientBuilder.build() doesn't expose the exact client type.

Solution

Expose the client type `KetamaClient` in the build() API.

from github: https://github.com/twitter/finagle/pull/280
Signed-off-by: Steve Gury <stevegury@twitter.com>- Problem

RB_ID=384391