fix(executor, frontend): BatchHopWindow executor should derive window expr in frontend

[jon-chuang]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Batch Hop executor should derive expr in frontend. e2e test previously panicked with variable duration interval due to not inlining session timezone.

Next step: stream

Checklist For Contributors

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
• All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

• My PR DOES NOT contain user-facing changes.

Related

Fixes part of: #7334

[codecov]

Codecov Report

Merging #8403 (e76a194) into main (03df818) will decrease coverage by 0.01%.
The diff coverage is 75.72%.

@@            Coverage Diff             @@
##             main    #8403      +/-   ##
==========================================
- Coverage   71.62%   71.62%   -0.01%     
==========================================
  Files        1135     1135              
  Lines      185248   185458     +210     
==========================================
+ Hits       132689   132837     +148     
- Misses      52559    52621      +62     

Flag	Coverage Δ
rust	71.62% <75.72%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/batch/src/executor/hop_window.rs	68.18% <58.82%> (-0.80%)	⬇️
...ontend/src/optimizer/plan_node/batch_hop_window.rs	72.56% <76.92%> (+1.79%)	⬆️
src/expr/src/expr/test_utils.rs	78.39% <77.88%> (-1.61%)	⬇️
...tend/src/optimizer/plan_node/logical_hop_window.rs	95.81% <79.06%> (-3.68%)	⬇️
src/batch/src/executor/group_top_n.rs	68.23% <0.00%> (-6.48%)	⬇️
...torage/src/hummock/local_version/pinned_version.rs	88.75% <0.00%> (-0.63%)	⬇️
src/meta/src/hummock/mock_hummock_meta_client.rs	65.46% <0.00%> (-0.52%)	⬇️
src/common/src/types/ordered_float.rs	32.62% <0.00%> (-0.20%)	⬇️
src/storage/src/hummock/compactor/mod.rs	80.38% <0.00%> (-0.20%)	⬇️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[st1page]

generally LGTM.
A potential problem is that it might produce a large plan node. It might be critical in serving situations(with high QPS). But I think the window TVF is hardly used in that situation. So it is not necessary to do that optimization prematurely.

[jon-chuang]

It might be critical in serving situations(with high QPS). But I think the window TVF is hardly used in that situation. So it is not necessary to do that optimization prematurely.

Yes, it does not seem too likely to use a hop window in serving scenario.