Currently measurement always needs to happen on the main thread if implicit hierarchy management is enabled as adding and removing from nodes needs to happen on the main thread. We now will trampoline to the main thread to do the insertion and deletion of nodes.
This also resolves the issue that can occur if a node is already loaded deep in the layout hierarchy in the layout that the node is transforming to. Before insertion or deletion is happening we need to crawl the layout hierarchy to check that though.
* [ASTableView] constrainedSizeForRowAtIndexPath
* Quick fix to header file
* Switch to Delegate from DataSource.
* Update testing variables to reflect switch to delegate
* [ASDataController] Add some assertions to clarify what queues things happen on
* [ASCollectionDataController] Optimize willReloadData
* [ASDataController] Minor optimizations, no functional changes
* [ASDataController] Always reload data on _editingTransactionQueue
* [ASDataController] Remove async data fetching option, deprecate callbacks
* [ASDataController] Not mutable
* [ASMultidimensionalArrayUtils] Use fast enumeration
* Optimize ASMultidimensionalArrayUtils
* Don't relayout as a result of clearing a traitCollection's context
I'm not completely sure this change is the best solution. Here is context:
An ASEnvironmentTraitCollection has a pointer to an optional context that an ASVC is the owner of. When the ASVC is dealloc'ed, we go through all subnodes of the VC and clear out the context so that the struct isn't holding on to a garbage pointer.
Setting the traitCollection on ASCollectionNode/ASTableNode causes the cells to relayout if the trait collection changed (this is a special case for these two nodes since their cells are not actually subnodes). Setting the context to nil registered as a trait collection change and was causing a layout even as we were dealloc'ing the VC.
The logic I'm implementing here is:
If the trait collection changed AND the displayContext did not, then we should relayout.
If the trait collection changed AND the new displayContext is non-nil then we should layout
In the case where the trait collection change was caused soley by the displayContext going from non-nil to nil, then we should NOT layout.
```
// At this point we know that the two traits collections are NOT equal for some reason
BOOL needsLayout = (oldTraits.displayContext == currentTraits.displayContext) || currentTraits.displayContext != nil;
```
Is there a better place/safer way to do this?
* removed extra setNeedsLayout call
* Fix some concurrency problems detected by Xcode 8's new Thread Sanitizer.
Some of these changes are arguably just to silence the warnings from Thread Sanitizer.
* Fix several memory leaks in the unit tests.
A number of the unit test source files are compield with `-fno-objc-arc`. This was clearly overlooked when writing several of the unit tests.
Fixed by (mostly) switching to use of `-autorelease` for the problem code.
NOTE: This commit doesn't fix all the memory leaks found. There's still at least one leak in `-[ASDisplayNodeTests testSetNeedsDataFetchImmediateState]`, and several leaks in `ASBasicImageDownloader.mm`. I wasn't able to find a trivial cause to these, unfortunately.
