GH-45690: [C++][Parquet] Consolidate Arrow write functions under TypedColumnWriterImpl

[kszucs]

Rationale for this change

I am planning to introduce WriteBatchInternal and WriteBatchSpacedInternal private methods in #45360 which would have required specifying WriteArrowSerialize, WriteArrowZeroCopy and WriteTimestamps as friend functions. Then I noticed that these functions could be consolidated into the column writer making the implementation simpler.

What changes are included in this PR?

• Move WriteArrowSerialize, WriteArrowZeroCopy and WriteTimestamps to be methods on TypedColumnWriterImpl.
• Remove the column writer argument, reorder their parameters to align with WriteArrow public method.
• Use more explicit type parameter names.

Are these changes tested?

Existing tests should cover these.

Are there any user-facing changes?

No, these are private functions and methods.

Resolves#45690

• GitHub Issue: [C++][Parquet] Consolidate Arrow write functions under TypedColumnWriterImpl #45690

[kszucs]

Since the implementation uses both parquet and arrow types, I thought it is better to be explicit. I can restore the previous name though.

[wgtmac]

This makes sense and already used by some functions in this file.

[pitrou]

Since the implementation uses both parquet and arrow types, I thought it is better to be explicit.

+1

[kszucs]

Consistently using the same argument order as WriteArrow.

[github-actions]

⚠️ GitHub issue #45690has been automatically assigned in GitHub to PR creator.

[wgtmac]

This makes sense and already used by some functions in this file.

[pitrou]

What if array.null_count() != 0 here?

[kszucs]

This is the existing logic, I haven't changed it.
I there are actually null values in the array not just being nullable, then we need to pick the slower path.

[wgtmac]

What if array.null_count() != 0 here?

It should not happen when the field is required but has null values: https://github.com/apache/arrow/blob/main/cpp/src/parquet/column_writer.cc#L1324

[pitrou]

Ok, thanks. Ideally we would have a DCHECK but since this is just moving code around we'll live without it.

[pitrou]

I posted some minor comments and suggestions, but this LGTM on the principle.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 6b66c84.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 16 possible false positives for unstable benchmarks that are known to sometimes produce them.