[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