Fix DataGrid not updating on collection Move operations

[xfortin-devolutions]

Fix DataGrid not updating on collection Move operations

Summary

• Add NotifyCollectionChangedAction.Move handling to DataGridCollectionView.ProcessCollectionChanged, which translates Move events from the source collection into Remove+Add events that the DataGrid already knows how to process
• The insertion index is computed from the event args to account for AvaloniaList.MoveRange reporting NewStartingIndex in the original (pre-removal) index space
• No-op moves (where the target index falls within the moved block) are detected and skipped
• Move handling for grouped DataGrids and direct NotifyingDataSource_CollectionChanged is left as future work (marked with TODO comments)
• Add a "Collection Mutations" tab to the sample app to exercise Add, Add Range, Remove, Move Up/Down, and Move In Place operations against a DataGrid backed by an AvaloniaList

Known limitations

• Grouped DataGrid scenarios (CollectionViewGroup_CollectionChanged) do not handle Move yet

[grokys]

Thanks for the PR! Having experience of this problem in the past, I knew where to look: selection ;) I've created a branch with a number of tests, some of them failing, many of them around selection.

Other than the bugs hightlighted in this branch, one of the things to decide is:

With this PR, when a selected item is moved, the selection remains at the same index and a different item gets selected. Is this OK? At first I thought that this was totally acceptable, but then I noticed that you're working around this in the sample, which suggests that it isn't ideal behavior?

There are tests for this in the branch but it might warrent discussion as to what the desired behavior is.

Other than that, I would ask for more tests in general for this new functionality. I know that this control is really lacking unit tests, but it would be nice to cover at least new functionality.

[grokys]

This is the workaround that I'm referring to.

[xfortin-devolutions]

I would agree that this is not ideal. I'd say, on a user point of view, I would expect my selection to remain the same after a move. That is, all the items (not indices) that have been moved, if they were selected, should remain selected.

In fact, most of the time, a move would imply the selection anyway. I can look into handling this correctly at the control level.

As for more tests, you mean, additionally to the one you've added?

[grokys]

Yeah the tests I added were just around the areas where my spidey senses told me there might be issues. Would be good to get more tests of the basic move behavior too.