Currently within `ASCollectionView`, there is an assumption that there will always be a static number of supplementary views per section—even when additional items are added or removed from that section. This is evidenced by the fact that when you invoke -[ASCollectionView insertItemsAtIndexPaths:], the data source method -[ASCollectionDataSource collectionView:nodeForSupplementaryElementOfKind:atIndexPath:] is not invoked, preventing consumers from specifying a new number of supplementary nodes for the new set of items.
With this change, the set of supplementary nodes for a section is now recalculated not only on section-level mutations, but also on item-level mutations as well. This adds item-level counterparts to the section-level `-prepareFor...` subclassing hooks in `ASDataController+Subclasses.h` to make this possible.
This should fix#1278 and #1322
This has been tested in my project and seen to fix the assertion. Open to suggestions on how to test in a more universal way.
- It is a container object that holds enough information to construct and measure a cell node
- All information is gathered on main thread. This allows ASDataController to capture the correct state of its data source before going to background.
The optimization seems correct now, but apps like Pinterest have some core code relying on edit operation
order that is actually not permitted by UIKit (and this diff) but were tolerated previously. We will
re-land this once we have time to adapt the code.
