fix: Validate filter selectivity at SET time

[subhramit]

Which issue does this PR close?

Part of #17498

Rationale for this change

datafusion.optimizer.default_filter_selectivity is documented as a percentage in the range 0 (no selectivity) and 100 (all rows are selected), but invalid values such as 200 are currently accepted by SET and only rejected later when the value is actually consumed during physical planning / execution.

So validating and rejecting out-of-range values at SET time to give users immediate feedback.

What changes are included in this PR?

• Add a validated ConfigFilterSelectivity wrapper type in datafusion/common/src/config.rs
• Change optimizer.default_filter_selectivity from u8 to ConfigFilterSelectivity
• Keep the default value validated via a dedicated helper used by config_namespace!
• Update the physical planner to read the raw u8 value via .get()

Are these changes tested?

Yes. The change is covered by datafusion/sqllogictest/test_files/set_variable.slt. It tests that:

• SET datafusion.optimizer.default_filter_selectivity = 200 fails immediately
• boundary values 0 and 100 are accepted

Ran cargo test --profile=ci --test sqllogictests -- set_variable.slt to confirm it passes, and also ran cargo test -p datafusion-cli and cargo test -p datafusion to check for any related regressions. There were none.

Are there any user-facing changes?

Yes.

As described above, users now get an immediate configuration error when setting datafusion.optimizer.default_filter_selectivity outside 0..=100, instead of seeing a later failure when the value is consumed.

This also changes a public config field type from u8 to ConfigFilterSelectivity, so it should likely carry the api change label (I request any maintainer to add this).

[subhramit]

cc'ing @Jefffrey, @2010YOUY01, @alamb
/ @xudong963, @comphead / @kosiew for CI run approvals
(as the guide instructs, although apologies in case I wrongly assumed "committers" to mean PMC members).

[codecov-commenter]

Codecov Report

❌ Patch coverage is 71.79487% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.31%. Comparing base (8332cfa) to head (eaa135f).

Files with missing lines	Patch %	Lines
datafusion/common/src/config.rs	70.27%	10 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #24541      +/-   ##
==========================================
- Coverage   81.32%   81.31%   -0.01%     
==========================================
  Files        1117     1117              
  Lines      396269   396307      +38     
  Branches   396269   396307      +38     
==========================================
+ Hits       322260   322273      +13     
- Misses      55186    55205      +19     
- Partials    18823    18829       +6     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Jefffrey]

do we have any other configs that could benefit from this? that way we might rename this to something more generic

[2010YOUY01]

Probably we can generalize it to a

pub struct ConfigRangeUsize {
    inclusive_min: usize,
    /// `None` if there is no maximum limit.
    inclusive_max: Option<usize>,
}

And several existing typed config structs can reuse this one (like ConfigNonZeroUsize)

But I think this is not blocking, we can clean it up in a follow-up PR

[2010YOUY01]

Thank you for working on it!