Support NotificationQueue on iOS/Android

Summary:
This is the last of the changes to make folly and thrift portable. The old
thrift SpinLock implementation is exactly we
want here so port this into folly. If someone later makes efficeint
versions of MicroSpinLock for platforms other than x64 they can easily
be plugged in without changing the calling code.

Test Plan: compiled on multiple platforms

Reviewed By: alandau@fb.com

Subscribers: folly-diffs@, ldbrandy, trunkagent, alandau, bmatheny, njormrod, mshneer, shikong, benyluo, kmdent, fma, ranjeeth, subodh

FB internal diff: D1621717

Tasks: 5183325
sync wangle to makefile

Summary: as above

Test Plan:

Reviewed By: davejwatson@fb.com

Subscribers: fugalh, njormrod

FB internal diff: D1589439
(FSM) updateState with unprotected action

Summary:
Like the magic macros. As it says in the comment, this can lead to nicer code.
Also added/moved a couple examples to the top of `test/FSM.cpp`.

Test Plan: new tests

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod

FB internal diff: D1618184
(wangle) dummy cpp files

Summary: for great contbuild

Test Plan: these projects still build. contbuild should start picking them up, based on discussion with @robbert

Reviewed By: robbert@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, mwa, jgehring, fuegen, njormrod, folly-diffs@, robbert

FB internal diff: D1624206

Tasks: 5399744
remove fireAndForget

Summary: It was deprecated, now is unused.

Test Plan:
fbgs
check contbuild

Reviewed By: hannesr@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1624221
(wangle) deprecate Later and ThreadGate

Summary:
Later is now superfluous. Just hold a deactivated future (e.g. one returned by `Future::via`), and then activate (or destruct) it when you're ready.
ThreadGate has proven to be too rigid and too heavyweight to be really useful. And is superfluous now with `Future::via`. e.g.
f.via(east).then(a1).then(a2).via(west).then(b1).then(b2);

This is stage one of removing these: mark them deprecated.
Stage two will be for me to change all existing usages in our code to not use them.
Stage three will be to rip these out altogether.

Test Plan:
Everything still builds and works, but now with deprecation warnings.

fbconfig -r \
common/smc/cpp/tests \
folly/wangle \
langtech/audiens \
messaging/avscan \
messaging/maelstrom \
neteng/traffic_manager \
notifications/nudge/service \
tao/client \
zeus/datashuttle
fbmake runtests

Reviewed By: jsedgwick@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1626412

Tasks: 5409538
(wangle) Core cleanup

Summary:
Just some cleaning hose in `detail::Core`.
- rename `fulfil` to `setResult`
- and `value_` to `result_`
- remove unnecessary helper methods (I can be convinced to keep them if you like them)

Test Plan: mechanical changes, tests still pass

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, folly-diffs@, net-systems@, fugalh, exa, njormrod

FB internal diff: D1618161
(wangle) express current Core functionality with a state machine

Summary:
This is a refactor of the current functionality to use a state machine (inheriting from `FSM`). This will make it easier to extend to do cancellation and Future collapsing. Performance is the same, maybe slightly faster (abt 1%). (I might be a little conservative with the atomics, it might be worth going through and reasoning about whether they all need to be atomic).

The state machine is two states, Waiting (no value), and Done (has a value). Transitioning to Done will execute the callback if it exists and we are active. Otherwise the callback will happen when it is set and active is true.

There is a subjective balancing act in place here, between making a state for every single mutable bit of information (which results in an explosion of states: hasValue X hasCallback X isActive X isCancelled …), and finding a sweet spot of expressivity. This isn't too far from the way Twitter did it, though we don't (yet) have all the states they have (and they don't have the concept of hot/cold futures). But I got there by way of replacing the `mutex_` with the state, after changing all those variables to atomics so they didn't need mutex protection (resulting in only `callback_` and `result_` needing it). I expect the state machine will morph as the rest of the functionality is added, but hopefully it will be easier to understand and keep correct (that's the idea anyway).

Test Plan: Tests still pass (and not by accident, I made several awesome mistakes along the way).

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod

FB internal diff: D1618240

Tasks: 4618297
(wangle) Interrupts (and therefore, cancellation)

Summary:
Modeled very closely after Finagle's interrupts. Compare with https://github.com/twitter/util/blob/master/util-core/src/main/scala/com/twitter/util/Promise.scala if you like.
The basic idea is the promise holder can register an interrupt handler, and then interrupts will call that handler. A typical handler would fulfil the promise with an exception (or special value) indicating that it was interrupted (if it was interrupted in time).
Raising an interrupt does not prevent setting a value or callbacks executing or any of that - it is only advisory to the promise holder.

Test Plan: I wrote some unit tests.

Reviewed By: davejwatson@fb.com

Subscribers: folly-diffs@, net-systems@, fugalh, exa, hannesr, njormrod

FB internal diff: D1620805

Tasks: 4618297
(wangle) Fix a couple compilation issues

Summary: If you try to include files in a weird (but not incorrect) order you get compilation errors. No longer!

Test Plan: new dummy `cpp_binary` target

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, folly-diffs@, net-systems@, fugalh, exa, njormrod

FB internal diff: D1621083
waitFor race workaround

Summary: Fixing the race will take some more thought. Probably a condvar. For now, I'm turning waitFor into a spinlock instead.

Test Plan: new unit test that deadlocks before the workaround

Reviewed By: jsedgwick@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1628015

Tasks: 5427828
(wangle) fix after-delete assert

Summary:
This would cause debug builds to do a bad thing (access the variable `this->detached_` within an assert, after `delete this`).

Test Plan: unit tests

Hopefully now that we have a dummy cpp file in `folly/wangle/detail` contbuild
will pick it up and all the dependencies will also run their tests.
Right now, we suspect maybe maelstrom (@wez) and adinvoicer and zookeeper
(@jying) and probably others are seeing this in unit test failures (esp. if
they use asan, which is rightly detecting read after free). Hoping contbuild
will catch them.

Reviewed By: davejwatson@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@, wez, dcapel, jying, cgheorghe

FB internal diff: D1630301

Tasks: 5424546, 5435720

Blame Revision: D1618240
Schedule destroyInstances in registrationComplete

Summary: This makes it more likely that SingletonVaultDestructor won't be created after atexit calls.

Test Plan: unit test

Reviewed By: chip@fb.com

Subscribers: hphp-diffs@, ps, njormrod, folly-diffs@

FB internal diff: D1629804

Tasks: 5353022
add PortableSpinLock.h to Makefile, unbreak fbthrift build

Summary:
fix fbthrift build, broken in D1621717

I wonder if it'd be possible to lint against this somehow. The jenkins failures are easy to miss especially on folly diffs with lots of failure noise (in this case it was still postponed)

Test Plan: wait for jenkins

Reviewed By: davejwatson@fb.com

Subscribers: njormrod, folly-diffs@

FB internal diff: D1630833
move asyncserversocket to folly

Summary:
Changes:
* namespace to folly
* some std::chrono replacesments
* Moves shutdownSocketSet stuff to thriftserver instead of in the socket itself.
* Changes exception types.  I don't see anywhere that uses the TAsync*SERVER*socket exceptions depending on the TTransport type, but I could be wrong? I don't really know what to do about the exception types

unittests still postponed overnight.

Test Plan:
fbconfig -r thrift; fbmake runtests
fbconfig -r proxygen; fbmake runtests

Reviewed By: dcsommer@fb.com

Subscribers: hphp-diffs@, ps, folly-diffs@, anca, trunkagent, jsedgwick, fugalh, doug, alandau, bmatheny, njormrod

FB internal diff: D1579187
fix Future<const T>::value()

Summary: I'm still a little mystified how one makes a Future<const T> (I tried to make one explicitly in a test and failed), but this is clearly the bug @reedriley sees in https://phabricator.fb.com/D1620805#21

Test Plan:
fbconfig titan/cachius/test
fbmake

Reviewed By: reedriley@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, reedriley, folly-diffs@

FB internal diff: D1630378

Blame Revision: D1620805
Revert "(wangle) express current Core functionality with a state machine"

Summary:

Test Plan:

Reviewed By: harishs@fb.com

Subscribers: net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1633874

Tasks: 5438209
Remove some leftover apache paths

Summary: EventBaseManager was moved to folly, we shouldn't have deps on apache

Test Plan: fbconfig -r folly/experimental/wangle/concurrency; fbmake runtests

Reviewed By: hans@fb.com

Subscribers: doug, fugalh, njormrod, folly-diffs@

FB internal diff: D1636006
unrevert "(wangle) express current Core functionality with a state machine""

Summary: Reverts D1633874. Companion to D1636490 which fixes the bug.

Test Plan:
git reverting code that was git reverted and hasn't changed in the interim
Won't be checked in without the companion bugfix diff (D1636490)

Reviewed By: davejwatson@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@

FB internal diff: D1636487

Tasks: 5438209

Blame Revision: D1633874
(wangle) fix race in Core::detachOne()

Summary:
In D1618240 I introduced a race condition in `detachOne()`, where `detached_` is incremented and then tested. If the promise and future are racing, they can both see `detached_ == 2` in the conditional, and then they'll both try to free the Core object. This fixes that.

It also fixes a related problem (which actually showed up more often with the test I wrote), where we transition into the Done state before setting the value, and then `maybeCallback()` observes the state is Done (because we're just reading an atomic, not grabbing the lock, which is intentional), tries to execute the callback, but `folly::Optional` throws an exception because the value hasn't been set yet (at least in debug it does). I should have listened to my gut and kept the state assignment after the transition action in the first place.

Test Plan: New unit test

Reviewed By: jsedgwick@fb.com

Subscribers: trunkagent, net-systems@, fugalh, exa, njormrod, folly-diffs@, mnd

FB internal diff: D1636490

Tasks: 5438209

Blame Revision: D1618240