This is not the final fix, but it will at least prevent the crash.

We still need to find the root cause of this because it causes headers to not be refreshed, leading to visual bugs.

It'll be interesting to see if this also reduces the crash rate on iOS 16.

Without this change we can see a crash in the app because the size for an unknown cell is requested. I think this is caused by the call to performBatchUpdates triggering a layout before the indexes have updated.

This works around a bug from ~iOS 14 that causes the last N items in a section to ignore any updates applied to them when N items are deleted from the same section and the items are at the end of the section.

This also removes the conversion of inserts/removals in to updates, which reduces the need to account for these synthesised updates and also more closely matches the intent of the user; if something has truly moved or been updated the appropriate methods can be used, while removals and inserts that happen to result in the same position will not animate as a refresh.

This also fixes the crash that #6 was originally aiming to fix. It became much easier to reason about the changes once the reloads were not synthesised and were using the post-updates index paths. I think this probably fixes some other bugs. At a minimum the existing tests were updated or still passed, plus new tests have been added.

I also created https://github.com/opennetltd/ComposedUITests/pull/1, which adds some more tests to the integration project. These are mostly used to validate that the unit tests here are correct according to UICollectionView, e.g. it does not crash, request any unexpected cells, or fallback to a reloadData.

This is an improvement but it's not quite a fix yet.

I think the issue is in the transforming of the index paths. We probably need to work with a mixture of the current and the transformed index paths in ChangesReducer.removeElements(at:) but I can't figure out the right mix and need to step away for a bit to clear my head of this, hopefully coming back with "fresh eyes."

I'm hoping this is a clearer API compared to using SelectionHandler.shouldSelect(at:) or SelectionHandler.didSelect(at:).