[feature](function) Support map arguments for inner_product

[BiteTheDDDDt]

What problem does this PR solve?

Issue Number: N/A

Related PR: N/A

Problem Summary:

inner_product currently only accepts dense ARRAY<FLOAT> vectors. This PR extends it to sparse vectors represented as MAP<K, FLOAT>, where matching map keys identify dimensions.

Map keys are intentionally limited to integral and string types. The BE dispatches to concrete native key types and hashes keys directly: numeric keys use their native column data, while string keys use zero-copy StringRef access. The implementation does not serialize keys or use runtime type erasure. For each row, it builds a flat hash map from the smaller input map and probes it with the larger map, using O(m + n) time and O(min(m, n)) temporary space. Existing dense array behavior remains unchanged.

The implementation also validates unsupported key types in FE and BE, preserves NULL-key matching, and rejects NULL map values and NULL outer maps.

Release note

Support inner_product(MAP<K, FLOAT>, MAP<K, FLOAT>) for integral and string key types.

Check List (For Author)

• Test
  • Regression test
    • test_map_inner_product
  • Unit Test
    • FunctionMapInnerProductTest.* (6 tests under ASAN)
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

Additional validation:

• DISABLE_BE_CDC_CLIENT=ON ./build.sh --be

• DISABLE_BUILD_UI=ON ./build.sh --fe

• build-support/check-build-hygiene.sh

• build-support/check-format.sh

• Behavior changed:

  • No.
  • Yes. inner_product now accepts compatible MAP arguments in addition to ARRAY arguments.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[BiteTheDDDDt]

run buildall

[hello-stephen]

FE UT Coverage Report

Increment line coverage 0.00% (0/12) 🎉
Increment coverage report
Complete coverage report