[CALCITE-6223] Add MAP_CONTAINS_KEY function (enabled in Spark library)

[caicancai]

https://issues.apache.org/jira/browse/CALCITE-6223

[caicancai]

@mihaibudiu @macroguo-ghy Sorry, there was something wrong with the branch management before, so I submitted a PR again.

[macroguo-ghy]

Left some comments

[caicancai]

@macroguo-ghy Would you mind helping me take a look, thank you

[macroguo-ghy]

I think as a committer of an Apache project, you must be an excellent engineer, but in this PR, you have made too many low-level errors, and even copied a lot of code from other places. I hope you can double check your code before submitting the PR.

I'm sorry for being a bit harsh, but I hope to save time for all contributors (including reviewers) in the Calcite community, as most of us participate in community activities during our personal time.

Another thing, try not to use rebase or square unless requested by the committer, otherwise reviewers can not check the diff between commits.

In order to update the pull request, you need to commit the changes in your branch and then push the commit(s) to GitHub. You are encouraged to use regular (non-rebased) commits on top of previously existing ones.
When pushing the changes to GitHub, you should refrain from using the --force parameter and its alternatives. You may choose to force push your changes under certain conditions:
the pull request has been submitted less than 10 minutes ago and there is no pending discussion (in the PR and/or in JIRA) concerning it;
a reviewer has explicitly asked you to perform some modifications that require the use of the --force option.

See details in develop guide.

[caicancai]

I think as a committer of an Apache project, you must be an excellent engineer, but in this PR, you have made too many low-level errors, and even copied a lot of code from other places. I hope you can double check your code before submitting the PR.

I'm sorry for being a bit harsh, but I hope to save time for all contributors (including reviewers) in the Calcite community, as most of us participate in community activities during our personal time.

Another thing, try not to use rebase or square unless requested by the committer, otherwise reviewers can not check the diff between commits.

In order to update the pull request, you need to commit the changes in your branch and then push the commit(s) to GitHub. You are encouraged to use regular (non-rebased) commits on top of previously existing ones.
When pushing the changes to GitHub, you should refrain from using the --force parameter and its alternatives. You may choose to force push your changes under certain conditions:
the pull request has been submitted less than 10 minutes ago and there is no pending discussion (in the PR and/or in JIRA) concerning it;
a reviewer has explicitly asked you to perform some modifications that require the use of the --force option.

See details in develop guide.

Thank you very much for your suggestions. Recently, the PRs of my two adaptation functions have caused a lot of trouble for everyone. In other words, some of my recent PRs have more or less made some low-level mistakes. I am also reflecting on myself and causing you problems. I'm sorry for bothering you. I won't make similar low-level mistakes again in the future.

[macroguo-ghy]

+1

Please squash your commit, I will merge it later.

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

2 New issues
0 Security Hotspots
90.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[caicancai]

Thank you for your review