[Data] Fixing handling of renames in projection pushdown

[alexeykudinkin]

Description

This change properly handles of pushing of the renaming projections into read ops (that support projections, like parquet reads).

Related issues

Link related issues: "Fixes #1234", "Closes #1234", or "Related to #1234".

Additional information

Optional: Add implementation details, API changes, usage examples, screenshots, etc.

[gemini-code-assist]

Code Review

This pull request introduces a significant improvement to projection pushdown by enabling column renames to be pushed into the read operations. The changes are well-structured, introducing a new utility for collapsing transitive rename maps and updating the logical operators and datasources accordingly. The core logic in the ProjectionPushdown rule correctly distinguishes between simple projections that can be fully pushed down and complex ones that require keeping the Project operator. I've identified a few areas for improvement, including removing leftover debug statements, adding a missing type hint for better maintainability, and minor code refinements for clarity and robustness.

[gemini-code-assist]

The variable next shadows the built-in function next(). It's a good practice to avoid shadowing built-ins to prevent potential confusion and bugs. Consider renaming it to something more specific like next_key or next_val.

Suggested change

	next = d[cur]
	next_val = d[cur]

[gemini-code-assist]

This function is missing a return type hint. Adding it would improve type safety and code clarity. Additionally, the logic for combining the dictionaries can be made more concise and robust against None values by using or {}.

def _combine_rename_map(
    prev_column_rename_map: Optional[Dict[str, str]],
    new_column_rename_map: Optional[Dict[str, str]],
) -> Dict[str, str]:
    combined = (prev_column_rename_map or {}) | (new_column_rename_map or {})
    return collapse_transitive_map(combined)

[srinathk10]

LGTM