Refactor cython interface: copying.pyx

[isVoid]

Part of #10153

Aside from the two harder cases: boolean_mask_scatter and sample that's been addressed in #10202 and #10262 , this PR tackles rest of refactors that's in copying.pyx, in combination of the other two, this PR should address all interface refactor in copying.pyx.

[codecov]

Codecov Report

Merging #10359 (f4349bd) into branch-22.04 (a7d88cd) will increase coverage by 75.73%.
The diff coverage is n/a.

@@                Coverage Diff                @@
##           branch-22.04   #10359       +/-   ##
=================================================
+ Coverage         10.42%   86.15%   +75.73%     
=================================================
  Files               119      139       +20     
  Lines             20603    22450     +1847     
=================================================
+ Hits               2148    19342    +17194     
+ Misses            18455     3108    -15347     

Impacted Files	Coverage Δ
...ython/custreamz/custreamz/tests/test_dataframes.py	99.39% <0.00%> (-0.01%)	⬇️
python/custreamz/custreamz/_version.py	0.00% <0.00%> (ø)
python/dask_cudf/dask_cudf/_version.py	0.00% <0.00%> (ø)
...ython/dask_cudf/dask_cudf/io/tests/test_parquet.py	100.00% <0.00%> (ø)
python/cudf/cudf/core/udf/pipeline.py
...thon/dask_cudf/dask_cudf/tests/test_distributed.py	86.79% <0.00%> (ø)
python/dask_cudf/dask_cudf/tests/test_dispatch.py	100.00% <0.00%> (ø)
python/cudf/cudf/core/udf/utils.py	98.63% <0.00%> (ø)
python/dask_cudf/dask_cudf/tests/test_accessor.py	98.41% <0.00%> (ø)
python/dask_cudf/dask_cudf/tests/test_join.py	100.00% <0.00%> (ø)
... and 105 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e9876cf...f4349bd. Read the comment docs.

[vyasr]

One important question about duplicating work and a couple of questions about establishing good patterns for APIs like this, but generally looks good.

[vyasr]

Something to think about: is there a better way for us to handle scalar vs column functions? We have this division in a lot of our Cython layers, can we think of a way to reduce it? One option would be to define generic scalar/column functions (not sure exactly what that would look like) and then passing specialized functions as arguments to handle different features. This is a very speculative idea, so no need to have an answer in this PR, but I do dislike duplicating this scalar/column division over and over.

[vyasr]

Some minor suggestions for improvement but it LGTM! I'll let you address the comments before merging.

[isVoid]

@gpucibot merge