QSortFilterProxyModel: create mappings on demand again

Calling create_mapping in setSourceModel as introduced by 8455bfee can lead to an early call to filterAcceptsRow, and some existing applications may crash. It is also an incomplete solution since it was only done for the toplevel index but not for child indexes.

Instead, go back to creating mappings on demand. This means coming up with a different fix for QTBUG-87781 (dataChanged not emitted for indexes that haven't been mapped yet, i.e. not queried or shown anywhere).

When this happens, we can't know if the index was previously filtered out or not (for lack of a dataAboutToBeChanged signal...). Creating the mapping with the new data only gives us the new state of affairs, there's no reference state to compare to. Therefore, when the mapping is missing (during dataChanged handling), create it, but skip all the logic about row insertion/removal, just forward the dataChanged signal if the row isn't filtered out.

Creating the mapping might require creating first mappings for parents, recursively, which wasn't done anywhere in QSFPM yet, hence the new create_mapping_recursive() method.

In addition to all this, the handling of removed items was incorrect, remove_source_items did nothing if the parent was gone, and then source_items_removed was trying to adjust indexes in an incorrect list. If the parent is gone, clear the proxy_to_source list, so there's nothing to adjust afterwards. This bug actually doesn't happen anymore in this version of the patch, but the change still seems right and might prevent repeating a long debugging session in the future.

Thanks to ChunLin Wang for the unittest in this commit.

Done-with: ChunLin Wang Pick-to: 6.1 6.0 5.15 Change-Id: Id543d0cc98f1a03b5852bda01d2f49b980e06be7 Reviewed-by: Qt CI Bot qt_ci_bot@qt-project.org Reviewed-by: Giuseppe D'Angelo giuseppe.dangelo@kdab.com (cherry picked from commit 4ec5622e)