Fix geopoint issue in complex data types

[vamsimanohar]

Related Issues

Partially Resolves #4324

Also, removed CalciteGeoPointFormatsIT.testReadingGeoHash as we have resolved the #3445

Currently, it handles only map case and we need to follow up with array and other complex scenarios.

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[penghuo]

yamlTest is much cleaner.
https://github.com/opensearch-project/sql/tree/main/integ-test/src/yamlRestTest/resources/rest-api-spec/test/issues

[opensearch-trigger-bot]

The backport to 2.19-dev failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/sql/backport-2.19-dev 2.19-dev
# Navigate to the new working tree
pushd ../.worktrees/sql/backport-2.19-dev
# Create a new branch
git switch --create backport/backport-4325-to-2.19-dev
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d527bbd93cef38b0b92ce80e2e86d0a4051997e8
# Push it to GitHub
git push --set-upstream origin backport/backport-4325-to-2.19-dev
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/sql/backport-2.19-dev

Then, create a pull request where the base branch is 2.19-dev and the compare/head branch is backport/backport-4325-to-2.19-dev.

[LantaoJin]

if the problem is we didn't cover the geo_point nested in a struct, why we need this? shouldn't be handled by https://github.com/opensearch-project/sql/pull/4325/files#diff-979074bb911fcfdb6b2eb25ab8b32da65cc8aa12b43b40b5880b876596f9c8d8R80?

[qianheng-aws]

That place can only handle the geo_point type in the 1st level of our mapping/schema. And it has special logic for handling the transformation that Avatica convert point into string.

For geo_point nested in a struct, we need do recursive parsing as it may be multiple-level nested. And when being nested in a struct, seems Avatica won't do that converting.

[LantaoJin]

For geo_point nested in a struct, we need do recursive parsing as it may be multiple-level nested.

L164-L171 is the logic of recursive parsing. question is why we need handle Point in L159-L162? can these lines be deleted? @qianheng-aws

[LantaoJin]

I see, the getExprValueFromSqlType cannot handle nested type. So the patch recursively resolves the type in processValue rather than getExprValueFromSqlType.