[GSProcessing] Fix ParquetRowCounter bug when different types had same-name features

[thvasilo]

Issue #, if available:

Description of changes:

• Previously, if some node/edge types shared the same feature names, we would end up overwriting the original feature name dict because we shared it between types.
• Now we create copies of the "data" dict for each type, and write the row counts directly to the corresponding type's dictionary, under the "row_counts" key.
• We also make the same fix for the graph structure entries (edges), although it's unlikely this would happen there.
• Finally used GenAI to generate some test cases for the file because it was untested before.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jalencato]

A few questions here:

• What shall we expect the row count here? The right count same to the original row count?
• Previously all node/edge types shared the same row count dict including all feature's information, but now it only stored the ones relative to itself. Will it bring any changes?

[thvasilo]

For the high level questions @jalencato

What shall we expect the row count here? The right count same to the original row count?

The row counter is used right after gs-processing has finished, and it counts the rows of each generated file for every node feature/mask/label, for each edge structure (src,dst) file, and for each edge feature/mask label.

gs-repartition uses these values as input to determine if re-partitioning is needed for any of the sets of files, as DGL assumes that all row counts for every node/edge type are the same.

In this case, what was happening was that some features that shared a name ended up without any row counts, because their key kept getting overwritten. Only the first-encountered key got to have row_counts, the rest had nothing. The "right" count is whatever that node's feature file counts actually were, before it was missing.

Previously all node/edge types shared the same row count dict including all feature's information, but now it only stored the ones relative to itself. Will it bring any changes?

In terms of expected input/output there won't be any changes, this just fixes the case where same-name features were not getting their row counts populated at all.

[jalencato]

LGTM