bench: add ASOF join benchmarks

[Xuanwo]

Which issue does this PR close?

• Part of ASOF join support / Specialize Range Joins #318.
• Umbrella PR: feat: support ASOF joins #23738.
• All required ASOF feature layers (feat: add ASOF join physical operator #23828 through feat: serialize ASOF join plans #23832) are merged.

Rationale for this change

This is the final core benchmark layer of the ASOF JOIN stack. It uses the
standard SQL benchmark framework so the workloads share the existing runner,
result format, and Criterion mode.

What changes are included in this PR?

• Add an asof_join SQL benchmark suite, runnable with
  ./bench.sh run asof_join or benchmark_runner.
• Add seven workloads covering relative input sizes, available ordering,
  equality-group cardinality and skew, match direction, and payload width.
• Describe each workload and its explicit ASOF match semantics in the query.
• Generate pre-sorted Parquet inputs for one keyed workload in its load hook and
  declare their ordering with WITH ORDER, keeping input sorting outside that
  measured query.
• Assert that every workload plans to AsOfJoinExec.

Are these changes tested?

Yes:

• cargo fmt --all
• ./ci/scripts/doc_prettier_check.sh --write --allow-dirty
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test -p datafusion-benchmarks --lib --bins
• cargo run -p datafusion-benchmarks --bin benchmark_runner -- asof_join --iterations 1 --partitions 4
• CARGO_COMMAND='cargo run' ./bench.sh run asof_join 1
• cargo run -p datafusion-benchmarks --bin benchmark_runner -- asof_join --query 7 --partitions 4 --criterion

The pre-sorted workload's physical plan contains AsOfJoinExec without an
input SortExec. These smoke runs validate the suite and are not presented as
performance claims.

Are there any user-facing changes?

This adds ASOF workloads to the repository benchmark tooling. It does not
change query semantics or runtime behavior.

This is the final core item tracked by #23738. It does not depend on the
optional floating-point follow-up #24375.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.88%. Comparing base (681705e) to head (f0690ba).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23833      +/-   ##
==========================================
- Coverage   81.88%   81.88%   -0.01%     
==========================================
  Files        1133     1133              
  Lines      424522   424522              
  Branches   424522   424522              
==========================================
- Hits       347622   347612      -10     
- Misses      56288    56294       +6     
- Partials    20612    20616       +4     

☔ 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.

[Xuanwo]

There are many optimizations to do, but I think it good to have a benchmark in first. This PR will be the last one of this stack, all other changes will be non-blocking, optional follow ups to do.

Cc @2010YOUY01 and @jayzhan211, let's go! Time to close the issue created 5 years ago 🤓

[jayzhan211]

Thanks @Xuanwo

Similar to nlj, hj, smj it would be nice to have ./bench.sh run asof

Some suggestions for more cases covered

[2010YOUY01]

Thank you for the fast iteration on this project! Here are some suggestions

I suggest we move the SQL benchmark to the new SQL bench framework, like https://github.com/apache/datafusion/tree/main/benchmarks/sql_benchmarks/nlj, so it would be runnable with

# under benchmarks/
./bench.sh run asof_join

Optional: To better explain the workload covered, we can write comments like

# top comment: axes to vary
#
# size: vary left/right input with very small / medium / large sizes, like 100/100k/10m rows
# sortedness: does the input already have the required order, or do we have to sort?
# group cardinality / size: ...

# per-query comment: just tag the axes
Q1: left small, right large; no existing order; single group ...

We can do this as a follow-up and potentially examine and try to better cover the typical workload.

[Xuanwo]

Thanks @jayzhan211 and @2010YOUY01 for the thoughtful reviews! This is much cleaner now 🙌

[jayzhan211]

👍🏻