Generate typedefs for cpp.type before forward declarations

Summary:
Before:
```
typedef std::unordered_map<int, xx::A> MapA;
class A;
```

After:
```
class A;
typedef std::unordered_map<int, xx::A> MapA;
```

Test Plan:
https://phabricator.fb.com/D1288386 works, and watch
contbuilt

Reviewed By: davejwatson@fb.com

FB internal diff: D1289520
Make the credentials cache update more atomic

Summary: We ran into problems before where reading / writing to a cache corrupted it. Doing this with a rename() makes it better.

Test Plan:
Rolled back fbcode before fix, then:
_bin/tupperware/twdeploy/twutil.par search webservers.intern

Reviewed By: mhorowitz@fb.com

FB internal diff: D1265741
tsocket: misspelling

Summary: I was running some code that hit an exception here.

Test Plan: uh no

Reviewed By: moshez@fb.com

FB internal diff: D1291247
Fix cc manager bug

Summary: See code. Right now it can access uninitialized memory.

Test Plan: None

// Need to override this since this is a mem corruption fix
@override-unit-failures

Reviewed By: mhorowitz@fb.com

FB internal diff: D1293087
Add TAsyncSSLSocket::setServerName()

Summary:
- Add TAsyncSSLSocket::setServerName() method to allow callers to set
the string to be used for the server_name TLS extension. This is
useful for applications that don't have full control over the
construction of TAsyncSSLSocket instances, which was the only
way to set this prior to this change.

Test Plan:
- Unit tests
- Ran experimental/rajatgoel2010:get; verified via tcpdump that we're
sending www.facebook.com in the server_name extension

Reviewed By: subodh@fb.com

FB internal diff: D1294060
Use decorator in generated process_xxx methods

Summary:
process_xxx methods read args with iprot, call handler then write result with oprot if there is. Use a decorator to move the read args and write result part to lib code.
pros: simpler code generator, more code in lib, generated code only contains the handler logic
cons: one more layer of indirection in generated code
@override-unit-failures

Test Plan: fbconfig thrift/test/py && fbmake dbg; fbconfig thrift/tutorial/py.twisted && fbmake dbg then run the twisted client and server

Reviewed By: alandau@fb.com

FB internal diff: D1284794
Renaming objects whose names are reserved in D

Summary:
When building a client in a new languages for an existing service, it might turn out that some identifiers used in the definition of the service (structs' fields, functions' args) are reserved in this language.

In this particular case, the ServiceRouter service uses the 'version' identifier for some fields/function args. Since the 'version' identifier is reserved in D, the generated code fails to compile.

(This diff is a follow-up to https://phabricator.fb.com/D1284635).

Test Plan: Compiled Rapido CLI (fbconfig rapido/cli && fbmake opt).

Reviewed By: andrei.alexandrescu@fb.com

FB internal diff: D1290643
Allow for PThreadThreads to be named before being created

Summary: There's actually quite a few "named" threads in the codebase that never get named because the current `setNameThread` will only work if its called after `start`. Try to fix that.

@override-unit-failures

Test Plan: See that the names of threads named in this manner become actually named.

Reviewed By: chip@fb.com

FB internal diff: D1291482
name the sasl threads and the notifcation thread

Summary: Thrift creates a bunch of threads outside the usual suspects (io/worker). Name them too.

@override-unit-failures

Test Plan: See the thread names in gdb.

Reviewed By: simpkins@fb.com

FB internal diff: D1291495
srproxy - do not send reply to SR2 one way clients

Summary:
Situation today: sr proxy sends replies to oneway clients - both sr1 sr2.  Technically, we only need to do that for sr1 clients according to the comments https://phabricator.fb.com/diffusion/FBCODE/browse/master/thrift/lib/cpp2/async/HeaderServerChannel.cpp;ef6a5f0090e1d6a213365c80067a6d0d9d26a9e8$186-190
but making the call conditioned on whether the client is thrift1 or thrift2, is really confusing.

Removing the log allows SR's code to be simpler.

@override-unit-failures

Test Plan:
ran the proxy locally
sent a few one way calls to it - observed that we only call sendReply
for sr1 clients.

Reviewed By: davejwatson@fb.com

FB internal diff: D1294927
Thrift1 Http protocol and 404 responses

Summary:
When using THttpAsyncChannel on the client in thrift1, a
reponse of 404 throws an error in THttpClientParser::parseStatusLine,
which is caught in TStreamAsyncChannel::invokeReadDataAvailable which
ultimately calls an error callback. If the error callback checks the
error with TStreamAsyncChannel::errorType, it will fail the DCHECK
because the real transport (socket) is good, and THttpAsyncChannel
doesn't override good().

The real fix would be go add a good() implementation to
THttpAsyncChannel, but this is thrift1 and is being phased out anyway.

Previous attempt at fixing in D1273704.

@override-unit-failures

Test Plan: test that it no longer crashes

Reviewed By: andrewcox@fb.com

FB internal diff: D1297027
Forward http GETS on service port to ServiceFramework

Summary:
Instead of opening a new port for ServiceFramework, just forward http gets on the service port.  THeader supports this pretty easily.  Some slightly clowny glue code to match everything up with proxygen

This approach still allows ServiceFramework to be default available without users having to pick another port - although they can still pick another port if they choose, or disable the GET forwarding by setting server->setGetHandler(nullptr) themselves.

Test Plan:
fbconfig common/services/cpp/test:Thrift2AsyncServer
fbmake dbg

Hit port 18083 with gets and pyremote, verify everything looks right. Didn't see any memory issues with valgrind.

Reviewed By: rajat@fb.com

FB internal diff: D1281240
Default to using folly::LifoSem

Summary:
Unless a service is overloaded, it should be able to clear
its queue frequently. When this happens, threads fall asleep until
more work is available in the queue. Waking up threads in LIFO
order gives us a lot of benefits. First, threads that were most
recently active are more likely to be mapped to the same cpu core
and thereby experience better L1 cache hit rate. Second, we can
madvise away jemalloc arenas on very idle threads. If we wake up
threads in FIFO order, we will never get a thread to remain idle
long enough for this to be worthwhile.

folly::LifoSem does just that. Benchmark in which the queue is
allowed to drain show that we get a substantial increase in
throughput by waking up threads in LIFO order.

Test Plan:
QueueBenchmark results summary:
As expected, benchmarks run faster in the case where the queue is
able to frequently drain itself, particularly in cases where the
number of threads is large. Benchmarks run slower when the
consumers cannot keep up with the producers, particularly when we
reach the queue capacity and we need to synchronize between
producers and consumers. However, in this case I think we care
less about the overhead of the queue itself and more about how
quickly we can shed the actual underlying load.

Reviewed By: davejwatson@fb.com

FB internal diff: D1298343
Fix text in exception in thrift generator

Summary:
Right now this generates php errors like:
"Required field timecannot be found."
It's missing a space

Test Plan: I'm not exactly sure how to run this generator, but this fix seems correct :)

Reviewed By: alandau@fb.com

FB internal diff: D1297713
Fix union read

Summary: Union's read method is broken because it only reads the (only) field and skips reading the field stop. Change to use a while loop and add an assert to make sure only one field is set.
@override-unit-failures

Test Plan: Test case in P9428189 + P9428210 works.

Reviewed By: andrewcox@fb.com

FB internal diff: D1297605
(1/3) eliminate/exclude a bunch of PMD warnings in prometheus + deps

Summary: these are all basically trivial

Test Plan: titest, fbcode contbuild tests

Reviewed By: ryandm@fb.com

FB internal diff: D1273391
fix opensource build

Summary: Missing file.  currently jenkins only runs 'make' not 'make test', I'll add make test after this

Test Plan: make test on ubuntu.

Reviewed By: alandau@fb.com

FB internal diff: D1302540
add entry points for credential-related operations

Summary:
This includes a new Krb5Credentials class which includes a
krb5_creds struct as a member, and methods to get new creds from a
keytab, get new creds from a tgt in a ccache, and store and retrieve
ccache entries.

This does include the first non-trivial wrappers in the form of the
retrieveCred and getCredentials overloads which take a krb5_principal.
This is by far the common use case and the only way we actually use
the functions in the code base.

Test Plan:
refactored separate perf code to use the new methods, and
verified they worked as expected.

Reviewed By: andrei.bajenov@fb.com

FB internal diff: D1301940
Easy: fix build with -Wshadow

Summary: Some projects are built with -Wshadow, and this fails.

Test Plan: fbconfig memcache/mcrouter && fbmake dbg

Reviewed By: gunjan@fb.com

FB internal diff: D1305565

@override-unit-failures
Mutex benchmark

Summary:
A load test of a production service showed that replacing a usage of thrift's Mutex with std::mutex had significant performance improvements. This benchmark is designed to help understand why there was such an improvement to try to rule out load test inconsistencies.

The results show that in the happy case, std::mutex is slightly faster in its constructor and in its lock methods. Contention tests are very similar. However, one interesting test case is one in which we thrash jemalloc by making many large malloc calls from lots of threads at the same time. Constructing a thrift mutex can take upwards of 20us (at least) in the test. The production service that saw the improvement from switching is known to have too much contention in malloc, so this may explain the performance win (every malloc is a place where the thread can be blocked on a lock, get context switched out, and sit in the run queue for some time. This service not only hammers malloc, but has a tendency to run completely out of cpu).

Test Plan: This is a benchmark

Reviewed By: davejwatson@fb.com

FB internal diff: D1306318