feat: Add new input_file_name UDF for file-backed scans

[AdamGS]

Which issue does this PR close?

• Closes Add input_file_name built-in function #6051.
• Closes feat: add input_file_name() for file-backed scans (plumbing PR) #20071
• Part of [EPIC] A collection of support for metadata columns in ListingTable #20135.

Rationale for this change

Adds useful metadata functions to DataFusion. This PR builds on @ethan-tyler's #20071.

What changes are included in this PR?

1. A new input_file_name() UDF, which reports a UTF8 return_type. Like file_row_index(), it errors when evaluated out of context.
2. Add rewrites in the FileOpener (Both in ParquetOpener and ProjectionOpener), making it a literal with the file's path.
3. New public rewrite helper rewrite_input_file_name_in_projection in datafusion-physical-expr-adapter.

Are these changes tested?

1. Unit tests in all rewrite-sites and for the core rewrite logic
2. New SLT tests working on CSV
3. New SLT testing metadata functions specifically on Parquet which has its own opener. These include file_row_index().

Are there any user-facing changes?

• The new UDF
• New public function in datafusion-physical-expr-adapter - rewrite_input_file_name_in_projection.

AI was used in this PR, mostly when helping to come up with test cases.

[AdamGS]

@alamb you mentioned in a previous review your dislike of all the helpers that keep accumulating in schema_rewriter.rs. I think that after this I'll try and figure out a better place to put them - even a dedicated file would be much nicer.

[alamb]

Thank you @AdamGS -- this makes sense to me. I had a few small comments, but otherwise it looks 👌

[alamb]

that is an interesting point -- can we add a note to the upgrading guide (and the release notes) and explain how to disable the function for people for whom it will be a security problem?

Maybe the explanation is just "register a function with the same filename" 🤔 Or should we add a config flag as a follow on PR to avoid registering these 🤔

[alamb]

I suggest consolidating the the parquet tests in datafusion/sqllogictest/test_files/input_file_name.slt so the tests for the same function live together in the same file

[AdamGS]

Will do. Do you think there's value in having tests for Parquet that do both in this file?

[alamb]

yes definitely

[alamb]

It occurs to me that we might want to add some documentation (as a follow on PR) to the TableProvider about functions that might need special handling (e.g. input_file_name, input_row_number, get_field)

Otherwise people implementing table providers might not know it would be helpful

[ethan-tyler]

Looks good to me

[Jefffrey]

I wonder if we should be returning an error or try be more permissive and return null/empty string for this case 🤔

For reference, Spark seems to return an empty string:

>>> spark.sql("select input_file_name()").show()
+-----------------+
|input_file_name()|
+-----------------+
|                 |
+-----------------+

[AdamGS]

file_row_index() also errors, I think its nicer because it makes it harder to misuse, I can imagine in some complex query a call might be misplaced, with results becoming unexpected.

[alamb]

I think @AdamGS 's implementation of file_row_index() did return NULL rather than an error (and I suggested returning an error).

I don't have a strong preference either way, as long as we have test coverage for the behavior