Revert "Switch to the MySQL 5.6 client"

Dragon has encountered an issue with double close()'s, which is
an issue in the underlyng libmysqlclient library.

This reverts commit 9e5a733ca19b8a199eb7742f90e6c80e46860d1d.

Reviewed By: @tudor

Differential Revision: D1087701
Stop dumping HNI extension bytecode in Eval.DumpBytecode=1

This just needs to mask out the low bit the way normal
systemlib works.  If you want to print the extension bytecodes, you
can set Eval.DumpBytecode=3.

Reviewed By: @markw65

Differential Revision: D1087356
Improve assertion for pmethodCacheMissPath---update write lease comments

Reviewed By: @bertmaher

Differential Revision: D1083718
Allow magic property methods to be entered recursively

Common idioms in php require magic methods to be allowed to
be entered recursively.  This diff makes hhvm mostly match zend on the
behavior here: recursion is allowed until it hits the same magic
method for the same property on the same instance.  For now there are
still some slight divergences in cases where there are also declared
protected properties with the same name (and we'll differ for now in
some cases where zend SEGVs).

There are a few things still here that look like bugs in some object
property reference counting (at least one case with setop of an object
prop seems to leak a reference).  I've tasked them to look at later so
we can get this in, though.  (They aren't all related to magic
methods.)

Reviewed By: @swtaarrs

Differential Revision: D1083309
Fix a reference leak in setop

I think there are a couple others relating to dynamic
properties and magic methods, but this one is independent enough for
its own diff.

Reviewed By: @swtaarrs

Differential Revision: D1084106
Clean up and fix some bugs in setOpProp and incDecProp

These functions were a bit hard to understand, and both
contained a reference leak in cases involving magic getters.  There
were also some behavioral differences from zend with protected
properties that are fixed.  It's very tempting to try to template this
and combine the two functions---they're almost the same, but just
barely not quite, so I'm leaving them separate for now.

Reviewed By: @dariorussi

Differential Revision: D1084236
Add smart_new and smart_delete

Instead of manually calling placement new or destructors with
smart_malloc and smart_free.  Since these are type-aware, they also
can easily use smartMallocSize/smartFreeSize to make a smaller
allocation.

Reviewed By: @swtaarrs

Differential Revision: D1084270
Replace some CHECK/DCHECK macros with {always_,}assert

Facebook: OSS warnings are ok.

Reviewed By: @ptarjan

Differential Revision: D1084382
Update HHBBC fault funclet assumptions for try/finally changes

The main change is that fault funclets now can be coverted by
protected regions.  There were also some issues with having multiple
protected regions pointing to the same fault funclet, even though I'd
already updated the spec to make that legal.  This diff also changes
things to find funclet handler extents using the same logic as the
verifier (relying on funclet bodies being contiguous), since it's
easier to do than forward propagating in RPO until you find an Unwind
now that there can be try/catch blocks inside the funclets.

Reviewed By: @edwinsmith

Differential Revision: D1088288
Fix a bug I had in AsyncAwait's hhbbc implementation

AsyncAwait pushes an HHBC "Cell" flavor, which corresponds to
the TInitCell type in HHBBC (it can't be KindOfUninit).  Oops.

Reviewed By: aravind

Differential Revision: D1088391
There's no "if for" statement

This is for @alexmalyshev.

Reviewed By: @alexmalyshev

Differential Revision: D1088412
Taskify some TODOs for hhbbc

Made tasks; removed some comments.

Reviewed By: @edwinsmith

Differential Revision: D1088620
Disable some zend tests that are failing on master

Reviewed By: @dariorussi

Differential Revision: D1088692
Don't eagerly start threads after warmup

If we've requested a warmup phase, we limit the number
of threads initially, and then allocate more after a suitable
warmup period.

We don't need to eagerly alloate them though - we can stick with the
existing code which only allocates as necessary.

Reviewed By: @jdelong

Differential Revision: D1087578