GH-37710: [C++][Integration] Add C++ Utf8View implementation

[bkietz]

Rationale for this change

After the PR changing the spec and schema ( #37526 ) is accepted, this PR will be undrafted. It adds the minimal addition of a C++ implementation and was extracted from the original C++ Utf8View pr ( #35628 ) for ease of review.

What changes are included in this PR?

• The new types are available with new subclasses of DataType, Array, ArrayBuilder, ...
• The values of string view arrays can be visited as std::string_view as with StringArray
• String view arrays can be round tripped through IPC and integration JSON

• Closes: [C++][Integration] Add C++ implementation of Utf8View #37710

Relevant mailing list discussions:

• https://lists.apache.org/thread/l8t1vj5x1wdf75mdw3wfjvnxrfy5xomy
• https://lists.apache.org/thread/3qhkomvvc69v3gkotbwldyko7yk9cs9k

[felipecrv]

This changes the meaning of is_binary_like_type. For list-views I added new predicates and kept the existing predicates' semantics.

Illustrate in this graph https://gist.github.com/felipecrv/3c02f3784221d946dec1b031c6d400db

[pitrou]

I agree with @felipecrv btw. This may silently produce incorrect binary-view handling in operations not touched by this PR.

[bkietz]

These traits are used in very few places. I think the current arrangement is fine; "binary like" = has a byte array, "string like" = has a byte array which is utf8.

[bkietz]

I've made a follow up to address this #38204

[pitrou]

The question is whether these are used by third-party code. These are not internal APIs, and there is a risk that user code will then try to use binary view data in non-compatible routines, and get UB or data corruption.

[bkietz]

I've reverted the change to is_binary_like_type and is_string_like_type

[pitrou]

@bkietz Please make sure you rebase before merging, since these are rather large changes that could unwillingly affect other parts of the code.

[paleolimbot]

@assignUser It looks like at least one CI job is using the latest nightly a little too oportunistically and causing the CI to fail here! https://github.com/apache/arrow/actions/runs/6658040302/job/18094056322?pr=37792#step:6:21

[paleolimbot]

We'll add that to the PR cleaning up the edges on the (somewhat large) change to the R build system defaults. You can safely ignore that CI failure (or if you can't safely ignore it than I volunteer to fix it!)

[bkietz]

Thanks @paleolimbot ! I'll merge now

[conbench-apache-arrow]

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

There were 2 benchmark results indicating a performance regression:

• Commit Run on ursa-i9-9960x at 2023-10-26 22:16:07Z
  • dataset-serialize (Python) with dataset=nyctaxi_multi_ipc_s3, format=csv, selectivity=10pc
  • dataset-serialize (Python) with dataset=nyctaxi_multi_ipc_s3, format=csv, selectivity=100pc

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

[alamb]

Thank you for everyone who commented, reviewed and helped get this PR merged