This situation is relatively uncommon. If a user manually uses -[UIView addSubnode:], the convenience category method,
and then calls -[ASDisplayNode removeFromSuperview] -- we would bypass performing the actual removal as no supernode pointer
is set. After further consideration, the special handling here to support divergence between the supernode pointer and
the view / layer hierarchy is not something we need to maintain going forward, and removing it makes addressing this easy.
* [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
