ObjProf user nodes only

ObjProf user nodes only

Summary:
Objprof is a memory profiler. It measures how many instances of each PHP class exist in memory and how many bytes of memory each class takes.

There are **two** high-level goals of this diff:

=== Make Objprof smarter and more flexible ===

We do this by adding new features to Objprof and adding flags to control these features.

The main new features introduced are:

- __New default Objprof behavior__ (aka USER_TYPES mode) in which memory for internal classes (ones starting with HH\, like HH\Map, HH\Vector etc.) is correctly aggregated to their closest parent user class. This makes Objprof results far more accessible because instead of telling you that 90% of memory was in maps, sets, vectors etc it actually tells you what user-level classes were most expensive.

- __New Objprof API (called OBJPROF_PROPS)__ in which memory utilization is reported at the property level instead of at the class level. This is very actionable information because it tells you not just which classes in your product/domain are most expensive but which properties within those classes are most expensive. This new api writes to the "objprof_props" scuba dataset and can be forced to run by appending the URL with: &objprof_props_sample=1. It is also always enabled in production, like other Objprof APIs.

- Ability to mark a subset of user classes as internal (and have their memory aggregated to their closest parent user class). This applies only to manually profiled requests as it involves canary'ing a SV change to your sandbox, and can be useful when debugging OOMs.

To summarize, we now report more useful results by default, and add a new dimension (per-property utilization) to Objprof results!

=== Switch from using HGObjprof to Objprof for the [[ https://our.intern.facebook.com/intern/wiki/Objprof | Objprof UI ]] ===

This is because Objprof is super efficient compared to HGObjprof. It does a one-time traversal of memory without duplicating things. On the other hand, HGObjprof involves generating a heap graph (expensive because it takes a snapshot of whatever is on the heap) and then traversing the graph to do the math of memory utilization. HGObjprof may very well cause a request that has OOMed to OOM again, or worse may cause the HHVM server to crash because there simply isn't enough memory available to generate the heap graph! For this reason, HGObjprof for OOMs is currently turned off in production (and therefore there is no data for OOMs in the Objprof UI).

Reviewed By: shai-d

Differential Revision: D3518586

fbshipit-source-id: 77becfb4a2f48c91ded5e2db2c45652cab1d65db