chore: move SanityChecker into physical-optimizer crate

[mnpw]

Which issue does this PR close?

Closes #14072.

Rationale for this change

From #14072

Historically DataFusion was one (very) large crate datafusion, and as it grew bigger we extracted various functionality into separate crates. This leads to both faster compile times (as the crates can be compiled in parallel) as well easier to navigate code (as the crates force a cleaner dependency separation)

What changes are included in this PR?

• Move SanityChecker from datafusion crate to datafusion-physical-optimizer crate

Are these changes tested?

Ran cargo test

Are there any user-facing changes?

No

[mnpw]

@alamb for your consideration.

I don't like that datafusion-physical-optimizer needs to use datafusion crate as a dev-dependency. This was required as SanityChecker tests were tightly coupled with the helper functions in datafusion::physical_optimizer::test_utils. Perhaps we can consider moving these helper functions somewhere outside, say, to test-utils crate?

[alamb]

I don't like that datafusion-physical-optimizer needs to use datafusion crate as a dev-dependency.

Thanks @mnpw -- I agree this is not good and we shouldn't merge it in like that (and in fact I think it failed the circular dependency check)

I think one of the major sources of this dependency is the use of ParquetExec which is still defined in the core module...

Since datafusion already depends on phsyical-optimizer, what would you think about moving as many of the physical optimizer utils from

• https://github.com/apache/datafusion/blob/main/datafusion/core/src/physical_optimizer/test_utils.rs
  To
• https://github.com/apache/datafusion/tree/main/datafusion/physical-optimizer/src/test_utils.rs
  As possible?

[alamb]

Converting to draft given the dependency situation we have uncovered