Add tests that show the different defaults for ArrowWriter and TableParquetOptions

[wiedld]

Which issue does this PR close?

Part of #11367
This PR defines the current state.

Rationale for this change

When we switched from using the parquet's ArrowWriter (with options) to the parallelized parquet writer (with it's own options), we ran into unintended behaviors due to different default settings.

Here are the places where the current defaults differ:

setting_name	applied	default, datafusion (ParquetOptions)	default, parquet (ArrowWriterOptions)
data_page_row_count_limit	file	usize::MAX	20_000
column_index_truncate_length	file	None	Some(64)
compression	column default	zstd	uncompressed
dictionary_enabled	column default	None or true †	true
statistics_enabled	column default	None or page †	page
max_statistics_size	column default	None or 4096 †	4096

† For these settings, datafusion has no default (None). However, once datafusion's ParquetOptions are used by the extern parquet (a.k.a. converted to parquet's ArrowWriterOptions) then it uses the extern parquet's defaults. Refer to the newly added tests.

.

Additionally, there are differences in the bloom filter configurations based upon partial definition (a.k.a. leaving some as default, and some as defined):

bloom_filter_on	fpp	ndv	if build from datafusion's ParquetOptions	if build from (arrow-rs) parquet's WriterPropertiesBuilder
false	none	none	None	None
TRUE	none	none	Some(BloomFilterProperties::default)	None
true	SOME	none	Some(BloomFilterProperties: fpp,default_ndv)	None
true	none	SOME	Some(BloomFilterProperties: ndv,default_fpp)	None

What changes are included in this PR?

There are no functional changes in this PR.

This PR is adding tests to define and demonstrate the differences in the defaults. After discussion and consensus, we'll have a follow up PR for implementing any desired changes.

Are these changes tested?

Yes, it's only tests.

Are there any user-facing changes?

No.

[wiedld]

Coincidentally, the treatment of these defaults just came up in discussion regarding memory debugging. What these writer props are (when actually doing the encoding), have an impact.

This PR is defining the current behavior only.
Not defining what it should be (altho yes the test cases use "should" lingo 😆 ).

[alamb]

Thank you @wiedld -- I think this looks great.

Since this is a test only change, I am going to merge it quickly so then we can make a PR to change the actual values

[alamb]

This PR is defining the current behavior only.
Not defining what it should be (altho yes the test cases use "should" lingo 😆 ).

I changed the title to reflect what this PR does 🙏 (as that shows up as the final commit message in the logs)

In general it is my opinion that the DataFusion defaults should mirror the arrow defaults -- I believe that was the intention when @devinjdangelo made the first version of this code. Over time the defaults in arrow have evolved and DataFusion hasn't kept up.