* [ASDataController] Avoid flushing editing queue before starting data controller pipeline
Step 1 of the pipeline is on main thread and needs pendingMap which was updated by the end of step 1 of the run. And step 1 operates on data source index space. So it should be ok to start it ASAP -- without waiting for any running work on the background editing queue.
One potential race condition after this change is that it's possible for main thread to query the data source (step 1) while the editing queue consumes the last change set (step 3). However, as long as the client's each nodeBlock and the node's layout code capture/reference an individual model object (as opposed to the whole data set) -- which is what clients are supposed to do anyways, then everything should be fine.
The benefit of this diff is that the pipeline will be able to accept many more change sets within a short time window, for example when clients submit a burst of separate small updates.
I tested this diff against our test suite several times and smoke tested it in our code base without any issues.
* Wrap in an experiment
* Enable experiment in tests
* Minor change
* Convert the codebase to Objective-C++ throughout. One language is better than two.
* Put it back
* Fix linker
* Point explicitly to updated Weaver to unblock build
* Revert "Point explicitly to updated Weaver to unblock build"
This reverts commit fdc25296e8794d4e6e56c35f5fe6da2be3f71dbc.
* Revert "Fix linker"
This reverts commit 7be25f91519b8497ef42de79f115bcfbdb965c39.
* Add in the frameworks
* no message
* Address spec lint warnings
* Fix tvos build
* Put that back
* Address Michael's review
* Add comment to kick CI
Huy Nguyen
Adlai Holler