GH-49415: [C++] Don't change map type key/item/value field names

[kou]

Rationale for this change

The current implementation forces using key/value/entries as key/item/value field names and ignores field names in FlatBuffers.

What changes are included in this PR?

Use field names in FlatBuffers.

Are these changes tested?

Yes.

Are there any user-facing changes?

Yes.

This PR includes breaking changes to public APIs. If an application depends on key/value/entriesas map type's field names, an application may not work when incoming Apache Arrow data doesn't usekey/value/entries` as map type's field names.

• GitHub Issue: [C++] Map type ignores key/item/value field names #49415

[github-actions]

⚠️ GitHub issue #49415 has been automatically assigned in GitHub to PR creator.

[kou]

@wgtmac @lidavidm @wjones127 What do you think about this? This code was changed by #35298 and you worked on the PR.

[lidavidm]

I wonder if any users may have inadvertently come to depend on this behavior. Should we highlight it as a potentially breaking change?

[wgtmac]

I think I've recently encountered a similar issue where Parquet and Arrow uses different hardcoded field names for map type: #49218 (comment)

[kou]

I wonder if any users may have inadvertently come to depend on this behavior. Should we highlight it as a potentially breaking change?

OK. I've updated the PR description for it.

FYI: @raulcd you may be a release manager for the next major release. We want to highlight this change in the release announce blog post.

[kou]

I'll merge this.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 0bddf5d.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 7 possible false positives for unstable benchmarks that are known to sometimes produce them.