Faster unique rows

[Huite]

Fixes #46

[Huite]

@veenstrajelmer

• Replaced all np.unique(..., axis=0) calls with a faster custom implementation.
• Rationale: unique relies on sorting; our implementation minimizes sorting operations.
• The order of generated connectivities (e.g., edge_node_connectivity) will differ from previous versions.
• When comparing datasets generated before and after this change, use reindex_like to ensure consistent ordering.
• Xugrid will still respect existing edge_node_connectivities, this PR doesn't change that behavior
• Expected speed improvements, among things merging the different topologies of the partitions: would be interesting to test

[veenstrajelmer]

I have tested this a few times with several datasets, keep in mind that for the second DCSM model caching is relevant so these timings are not from the first process. Caching is somehow maintained over multiple processes.

With xugrid 0.12.0:

DCSM nose
>> xu.open_dataset() with 5 partition(s): 1 2 3 4 5 : 18.80 sec
>> xu.merge_partitions() with 5 partition(s): 15.91 sec
>> dfmt.open_partitioned_dataset() total: 34.71 sec
DCSM
>> xu.open_dataset() with 20 partition(s): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 : 5.70 sec
>> xu.merge_partitions() with 20 partition(s): 12.30 sec
>> dfmt.open_partitioned_dataset() total: 18.08 sec
Westerschelde
>> xu.open_dataset() with 1 partition(s): 1 : 0.09 sec

Memory usage:

With the faster-unique-rows branch:

DCSM nose
>> xu.open_dataset() with 5 partition(s): 1 2 3 4 5 : 18.61 sec
>> xu.merge_partitions() with 5 partition(s): 15.65 sec
>> dfmt.open_partitioned_dataset() total: 34.27 sec
DCSM
>> xu.open_dataset() with 20 partition(s): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 : 5.78 sec
>> xu.merge_partitions() with 20 partition(s): 12.35 sec
>> dfmt.open_partitioned_dataset() total: 18.21 sec
Westerschelde
>> xu.open_dataset() with 1 partition(s): 1 : 0.09 sec

Memory usage:

Unfortunately, in all these testcases, there is no noticeable difference.

[Huite]

Based on these results: the sorting isn't taking enough time to make this worthwhile.
(I could've known this beforehand if I had profiled properly, but it's nice to have realistic tests anyway!)