twitter-server: Improve LoggingHandler

Problem

LoggingHandler mixed presentation with logic and was
difficult to follow and modify.

Solution

Refactor it and improve the presentation to make it
more usable, especially when rendered in the html.

RB_ID=528651
twitter-server: Improve client profile to take into account session health

Problem

The client profile only took into account the request path. That is, failures
to acquire a service or failing endpoints are not reflected in the success rate
and such failure modes are not surfaced in the /admin interface.

Solution

Include the number of unavailable endpoints as part of the profile. This should
adequately represent finagle's failure management (failure accrual, fail fast, etc).
Clients are still sorted w.r.t success rate.

RB_ID=529943
Set up SBT for 2.11 builds and remove StreamyJ dependency

Problem

We want to publish 2.11 versions of as many Finagle subprojects as possible.
Some subprojects can't be built for 2.11 at the moment, since they depend on
either Specs or Ostrich, neither of which have builds for 2.11. One subproject
(finagle-example) depends on StreamyJ, which also has no 2.11 build. We're also
using Jackson 2.3.1 internally, and the Jackson Scala module for that version is
not available for 2.11.

Solution

Because StreamyJ is used in a single test and nowhere else in Finagle, I've
simply ported the test to use vanilla Jackson, which allows us to remove the
dependency. The Jackson version used in the SBT builds for Finagle and
twitter-server now depends on the Scala version, and Finagle subprojects that we
can't build for 2.11 are excluded from the root finagle project. I've also
updated the Scala 2.11 versions in the SBT builds for Util and Scrooge from
2.11.2 to 2.11.4.

Result

We can publish 2.11 builds for twitter-server and all but five Finagle
subprojects. Note that finagle-example, finagle-ostrich4, finagle-redis, and
finagle-stress now must be tested and published individually, since they're no
longer aggregated by the root finagle project (this is similar to the current
status of util-eval).

RB_ID=532745
Introduce request contexts

Problem

This change solves two related problems.

1. The use of c.t.u.Local is fraught with potential misuse and
confusion. Finagle now delimits Locals in dispatchers, but there are
still many opportunities for misuse. The Local API is not conducive to
proper use. There have also been issues with leaks caused by misuse of
this API.

2. Finagle has no control over how request contexts are delimited. In
practice, they are backed by Locals, and thus suffer the same
problems. This causes confusion and bugs.

Solution

Provide a single, unified way of dealing with request-local data in
Finagle. We introduce type c.t.f.context.Context whose lifetimes are
managed by Finagle itself. There are two variants: Contexts.local
never escapes the local request graph, while Contexts.broadcast may
transit process boundaries, as is the case for current "request
contexts." This has the additional benefit of doing away with service
loading to support marshalled request contexts.

Most uses are ported over, including trace ids; some, like Dtab
locals, remain for porting over later.

Result

Fewer bugs, clearer code.

RB_ID=536961
TBR=true
3rdparty/BUILD: split up into package dirs - part 3 (jackson)

RB_ID=535565