[C++] Add variadic string join kernel

[asfimport]

Similar to SQL's concat and concat_ws. Should take 0, 1, 2, ... string arrays and an optional separator (default empty string) and concatenate them together, returning a string array.

For example, in the case of 2 input arrays and with the separator "-", this would take inputs:

Array<string>        Array<string>
[                    [
  "foo",               "bar",
  "push"               "pop"
]                    ]

and return output:

Array<string>
[ 
  "foo-bar",
  "push-pop"
] 

Should also accept scalar strings and recycle their values.

Reporter: Ian Cook / @ianmcook
Assignee: David Li / @lidavidm

Related issues:

• [C++] String algorithm library for StringArray/BinaryArray (is a child of)
• [C++] Add scalar string join kernel (relates to)
• [C++] String formatting kernel (is related to)
• [R][C++] Bindings for paste(), paste0(), str_c() (is depended upon by)

PRs and other links:

• GitHub Pull Request #10520

_{Note: This issue was originally created as ARROW-12709. Please see the migration documentation for further details.}

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:
From the point of view of the kernel, what's the exact difference with ARROW-12710 and ARROW-10959 ? (in all cases I expect a signature of "list, sep (optional) -> string" ?)

[asfimport]

Ian Cook / @ianmcook:
I added examples to the descriptions of all these string join kernel issues to make the distinctions between them clearer.

[asfimport]

Antoine Pitrou / @pitrou:
Do we want this kernel to be truly variadic or to take a struct array?

[asfimport]

Ian Cook / @ianmcook:
@pitrou the intent for this ticket is a truly variadic kernel, equivalent to the SQL string functions concat and concat_ws which join the strings across an arbitrary number of string columns. This is a common usage pattern in data warehouse-type queries.

For joining the strings in an array of list of strings, we have binary_join (ARROW-10959). That plus an adjoin_as_list function (ARROW-12739) gets us to the same result as this when the string-like columns have the same type, but my understanding is that the speed and memory usage of calling this variadic kernel will be much superior to calling adjoin_as_list then binary_join.

[asfimport]

Antoine Pitrou / @pitrou:
Yes, it would be much more performant to join at once instead of bearing intermediate allocations and copies.

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:

Do we want this kernel to be truly variadic or to take a struct array?

That's probably something we could ask ourselves for all variadic kernels (like the elementwise min/max that were added recently), and should probably be consistent about it?

[asfimport]

Antoine Pitrou / @pitrou:
I guess it depends on actual use cases.
Note that "struct array" would be more general, as it also allows top-level null bits. But that's only a concern if the user actually needs to pass a struct array (rather than a variadic list of arrays).

[asfimport]

Antoine Pitrou / @pitrou:
Issue resolved by pull request 10520
#10520