feat: rand expression support

[akupchinskiy]

Which issue does this PR close?

Closes #1198

Rationale for this change

Support of the spark rand() expression

What changes are included in this PR?

• rand() expression implementation
• partition-awareness of the planner

How are these changes tested?

Spark compatibility tests and expression correctness test are included in the PR

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 58.98%. Comparing base (f09f8af) to head (b95f4b7). Report is 282 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1199      +/-   ##
============================================
+ Coverage     56.12%   58.98%   +2.85%     
- Complexity      976     1141     +165     
============================================
  Files           119      130      +11     
  Lines         11743    12872    +1129     
  Branches       2251     2421     +170     
============================================
+ Hits           6591     7592    +1001     
- Misses         4012     4059      +47     
- Partials       1140     1221      +81     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[andygrove]

Thanks @akupchinskiy. I plan on reviewing this after the holidays.

[mbutrovich]

Are the partition related changes necessary for this PR? Otherwise, it might be better to reduce the scope to just the rand() expression.

[akupchinskiy]

Are the partition related changes necessary for this PR? Otherwise, it might be better to reduce the scope to just the rand() expression.

There is a handful of expressions besides rand() relying on the partition index. All of them implement nondetermenistic trait providing a hook method to initialize a state before a partition evaluation for spark runtime.

Encapsulation-wise, I agree that the scope of the partition exposure should be limited. But I could not find another way to extract it other than making it a part of a planner struct.

[kazuyukitanimura]

@akupchinskiy do you plan to resolve the conflicts?

[akupchinskiy]

@akupchinskiy do you plan to resolve the conflicts?

Yeah, thanks for the reminder. Will do it tomorrow

[akupchinskiy]

@kazuyukitanimura could you trigger the workflow?

[andygrove]

I upmerged this PR and re-triggered the workflows. Sorry for the delay @akupchinskiy