Support Preceding with negative indices in window function

[somu-imply]

This aims to solve #15739 by introducing a change in the native query plan for Windowing query where a query like

WITH virtual_table as (select m2 ,sum(m1) as summ1
from foo group by 1 order by summ1 DESC)
select m2,summ1,sum(summ1) OVER (order by m2 rows between 1 PRECEDING and 2 FOLLOWING) as sumfinal
from virtual_table order by 1

will be planned in the between 1 PRECEDING and 2 FOLLOWING part as

"processor": {
            "type": "framedAgg",
            "frame": {
              "peerType": "ROWS",
              "lowUnbounded": false,
              "lowOffset": -1,
              "uppUnbounded": false,
              "uppOffset": 2,
              "orderBy": null
            },
            "aggregations": [
              {
                "type": "doubleSum",
                "name": "w0",
                "fieldName": "a0"
              }
            ]
          }

This would allow us to support all the cases which postgres supports such as

between 1 PRECEDING and 2 FOLLOWING
between 2 PRECEDING and 1 PRECEDING
between 1 FOLLOWING and 2 FOLLOWING

This will also handle cases with a meaningful error where the upper offset is of a lesser value than the lower offset such as

between 1 PRECEDING and 2 PRECEDING
between 2 FOLLOWING and 1 FOLLOWING

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[kgyrtkirk]

seen the topic of the PR - didn't notice it was a draft and taken a quick look.... :)

[kgyrtkirk]

instead of adding if-s for both lower/upper - can we make these changes inside figureOutOffset ?

[kgyrtkirk]

I think this check should be in DruidSqlValidator ; it will need similar things like #15746

[kgyrtkirk]

I think you should also probably take a look at: WindowFrame#getLowerOffsetClamped
and the callsites of that method in this file

by the way: I think we should retire the old rows processing logic and leave that as well to the one handling the range stuff - it should be on-par in performance; but could handle some edge cases a bit better.

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If you think
that's incorrect or this pull request should instead be reviewed, please simply
write any comment. Even if closed, you can still revive the PR at any time or
discuss it on the dev@druid.apache.org list.
Thank you for your contributions.

[github-actions]

This pull request/issue has been closed due to lack of activity. If you think that
is incorrect, or the pull request requires review, you can revive the PR at any time.