[split] Birdcage on oss pants.

RB_ID=304943
[split] util-core: add Spool.collectFuture

Problem
When making RPCs in Spool reactions, you end up with Spool[Future[A]].
This is sometimes annoying since the tail of a Spool is already a future.

Solution
Add Spool#mapFuture

Result
Users don't need custom code to map or iterate of a Spool.

RB_ID=356811
[split] Add provides clauses to CSL BUILD files In preparation for publishing with pants, we can now add provides clauses without the build blowing up. NB: pants on master still doesn't publish, but this will help give devprod example libraries to test against.

RB_ID=358451
[split] finagle-mux: Modifies MuxService to essentially be a Service[Spool[Buf], Spool[Buf]] Problem

mux does not currently support chunked encoding of requests and responses.

Solution

Use the reserved high bit of the message tag to indicate that a message is to be continued.

Result

You can now stream a request or response using a Spool[Buf].

RB_ID=353023
[split] util-core: Introduce ConcatBuf

Problem

The old implementation of `Buf.concat` was returning an anonymous implementation of Buf as a
deeply nested tree. Any call to one of the methods of this Buf was potentially causing a
StackOverflowError

Solution

Introduce a new class ConcatBuf, which represents a linked list of Buf instead.

Result

Every call to a method of ConcatBuf is now iterating through the link list, which doesn't
consume the memory in the call stack.

RB_ID=362791
TBR=true
[split] More CONFIG.ini's

RB_ID=363427
TBR=true
[split] Add a take method to Spool.

Problem

Spool does not have a take method, which makes it hard to extract more than the head element from a spool.

Solution

Implement a take method along the lines of Stream.take. This method should preserve lazy evaluation of the Spool.

Result

Spool now has a take method which preserves laziness. Take the first n elements of a spool. one can do spool.take(n).toSeq

RB_ID=366809
[split] colony: Auth to ZK

RB_ID=363743
[split] twitter-server: productivity = cpuTime/wallTime

Problem

The 'productivity' metric in twitter-server is pretty much useless. It
only measures the ratio of cpu time spent in user mode vs. system
mode, it does not account for blocking.

Solution

We can make a gross-ish estimation of this by measuring wall time. A
thread's cpuTime/wallTime measures the proportion of time the thread
was "doing something." This is by no means perfect: for example, the
kernel scheduler may simply choose not to run the (otherwise runnable)
thread, it doesn't account for preemption, etc. etc.

I think it is reasonable to define 'productivity' in those terms, with
the caveat that a lack of 'productivity' is not always attributable to
blocking alone.

The metric may be attenuated by a mismatch in accuracy between CPU
time (presumed getrusage) and walltime measurements (which can be done
by reading a timing register).

RB_ID=368879
[split] birdcage: Upgrade 3rdparty libraries

Problem

In order to have more consistency in the 3rdparty libraries used by birdcage/science/tfe
and also to avoid conflict due to different build tools maven vs pants (ivy), this change
upgrade all the 3rdpartiy libraries in birdcage to match tfe/science.

Solution

Here's the list of changes:
- guava 16.0 => 16.0.1
- jsr305 => 1.3.9 => 2.0.1
- Upgrade com.twitter.common.* to the latest
- Upgrade com.twitter.common.zookeeper.* to the latest
- Upgrade com.twitter.common_internal.* to the latest

RB_ID=370102
[split] BridgedThreadPoolScheduler: forward flushes to local scheduler

Problem

BridgedThreadPoolScheduler treats flush()es as no-ops. This can cause
local schedules to be clogged up in Await.result() as it relies on
being able to do away with previously scheduled work.

Solution

Forward flushes to the current local scheduler, if any.

RB_ID=374802
[split] bump util to 6.17.1-SNAPSHOT

RB_ID=376056
TBR=true
NO-QUEUE=true
[split] util-app: Improve the Scaladocs for com.twitter.app.Flag and friends

In describing flag behavior in a support email, I found that there are
methods and idiosyncrasies of the flag library that could have clearer
documentation. This change rewords and adds a bunch of Scaladocs within
Flag.scala.

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

RB_ID=378107
TBR=true
[split] Signal the deprecation of com.twitter.util.Bijection.

Based on E-Mail thread: com.twitter.util.Bijection vs. com.twitter.Bijection

RB_ID=376008
[split] Add additional handlers to Logging trait.

Problem

There is no way to override the handlers that the default LoggerFactory uses in the Logging trait. The result is that if someone wants to add a handler to the root logger factory (e.g. for LogLens) they need to override and copy paste the whole method.

Solution

Add a method called handlers that can be overridden if needed. This initiates one handler by default, but it can be overridden if we need to add more handlers.

Result

It is now possible to easily configure LogLens for all applications.

RB_ID=375114
[split] Add U(32|64)(BE|LE) to Buf

RB_ID=361451
[split] util-core: Fix MockTimer#schedule(Duration)(=> Unit)'s cancel

Problem
MockTimer#schedule(Duration)(=> Unit)'s tasks cannot be canceled after it has already ticked.

Solution
Return a task which when cancelled, stops the entire task from continuing.

Result
MockTimer#schedule(Duration)(=> Unit)'s tasks no longer continue past when they should have stopped.

RB_ID=377357
[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] util-app: Don't kill the JVM on flag-parsing failure

Problem

Upon failure to parse a flag, c.t.app.App invokes `System.exit(1)`. It
seems too heavy-handed to force JVM death rather than have the caller
handle a RuntimeException (which would exit the process in the normal
case).

Solution

Introduce `FlagParseResult` case classes to represent the outcome of
flag parsing. Using these, a `Flags.parseArgs` method is provided to
serve as the preferred entry-point for flag parsing. `Flags.parse` is
deprecated and `Flags.parseOrExit1` is written in terms of the new
method, `Flags.parseArgs`.

This commit also adds some polish to the format of usage output
strings.

RB_ID=378167