Update black to 22.3.0, update usage of libcudf macros, and remove direct column indexing

[charlesbluca]

This PR resolves three separate issues caused by changes to our dependencies:

1. The version of Black we were using broke due to a change in click (xref black fails due to _unicodefun psf/black#2963). This PR bumps us to the latest version, which resolves those issues (and makes some minor styling changes).
2. rapidsa/cudf#10589 changed the CUDA_TRY macro to CUDF_CUDA_TRY and CHECK_CUDA to CUDF_CHECK_CUDA, so cuspatial needs to make that change as well.
3. rapids/cudf#10516 removed support for direct indexing of columns via __getitem__. This PR replaces those calls with the appropriate methods.

[charlesbluca]

rerun tests

[charlesbluca]

Getting build failures that seem unrelated:

$SRC_DIR/cpp/src/join/quadtree_poly_filtering.cu(186): error: namespace "thrust" has no member "stable_sort_by_key"
          detected during instantiation of "std::unique_ptr<cudf::table, std::default_delete<cudf::table>> cuspatial::detail::<unnamed>::dispatch_quadtree_bounding_box_join::operator()<T,<unnamed>>(const cudf::table_view &, const cudf::table_view &, double, double, double, int8_t, rmm::cuda_stream_view, rmm::mr::device_memory_resource *) [with T=float, <unnamed>=(void *)nullptr]" 
$PREFIX/include/cudf/utilities/type_dispatcher.hpp(456): here

$SRC_DIR/cpp/src/join/detail/traversal.cuh(123): error: namespace "thrust" has no member "constant_iterator"
          detected during:
            instantiation of "std::unique_ptr<cudf::table, std::default_delete<cudf::table>> cuspatial::detail::<unnamed>::join_quadtree_and_bboxes(const cudf::table_view &, const cudf::table_view &, T, T, T, int8_t, rmm::cuda_stream_view, rmm::mr::device_memory_resource *) [with T=float]" 
$SRC_DIR/cpp/src/join/quadtree_poly_filtering.cu(229): here
            instantiation of "std::unique_ptr<cudf::table, std::default_delete<cudf::table>> cuspatial::detail::<unnamed>::dispatch_quadtree_bounding_box_join::operator()<T,<unnamed>>(const cudf::table_view &, const cudf::table_view &, double, double, double, int8_t, rmm::cuda_stream_view, rmm::mr::device_memory_resource *) [with T=float, <unnamed>=(void *)nullptr]" 
$PREFIX/include/cudf/utilities/type_dispatcher.hpp(456): here

$SRC_DIR/cpp/src/join/detail/traversal.cuh(123): error: type name is not allowed
          detected during:
            instantiation of "std::unique_ptr<cudf::table, std::default_delete<cudf::table>> cuspatial::detail::<unnamed>::join_quadtree_and_bboxes(const cudf::table_view &, const cudf::table_view &, T, T, T, int8_t, rmm::cuda_stream_view, rmm::mr::device_memory_resource *) [with T=float]" 
$SRC_DIR/cpp/src/join/quadtree_poly_filtering.cu(229): here
            instantiation of "std::unique_ptr<cudf::table, std::default_delete<cudf::table>> cuspatial::detail::<unnamed>::dispatch_quadtree_bounding_box_join::operator()<T,<unnamed>>(const cudf::table_view &, const cudf::table_view &, double, double, double, int8_t, rmm::cuda_stream_view, rmm::mr::device_memory_resource *) [with T=float, <unnamed>=(void *)nullptr]" 
$PREFIX/include/cudf/utilities/type_dispatcher.hpp(456): here

3 errors detected in the compilation of "$SRC_DIR/cpp/src/join/quadtree_poly_filtering.cu".

[vyasr]

This failure is likely caused by the Thrust 1.16 update in libcudf. cugraph reported similar issues. If so, we'll likely need to resolve this upstream.

[bdice]

This failure is likely caused by the Thrust 1.16 update in libcudf. cugraph reported similar issues. If so, we'll likely need to resolve this upstream.

A libcudf fix to rollback Thrust to 1.15 has been merged. NVIDIA/cudf#10586

[harrism]

rerun tests

[vyasr]

rerun tests

[vyasr]

rerun tests

[vyasr]

NVIDIA/cudf#10589 changed the name of a macro that cuspatial was relying on. Since we need to make that change as well in order for tests to pass, I'm pushing those onto this branch as well.

[bdice]

rapidsai/cudf#10589 changed the name of a macro that cuspatial was relying on. Since we need to make that change as well in order for tests to pass, I'm pushing those onto this branch as well.

Are macros considered part of cuDF's public API? I am not sure if libcudf macros are supposed to be used outside of libcudf. RAFT, for instance, declares RAFT_CUDA_TRY rather than re-using libcudf's macros. cc: @jrhemstad @harrism NVIDIA/cudf#9660 NVIDIA/raft#128

[vyasr]

Are macros considered part of cuDF's public API? I am not sure if libcudf macros are supposed to be used outside of libcudf. RAFT, for instance, declares RAFT_CUDA_TRY rather than re-using libcudf's macros. cc: @jrhemstad @harrism rapidsai/cudf#9660 rapidsai/raft#128

No they are not, but cuspatial does so anyway. In general, cuspatial uses a significant number of cudf internals (in both C++ and Python) that we would like for it not to. @harrism and I have previously discussed a need to improve this situation, but it hasn't been prioritized given the relative pace of cuspatial over the past year. I don't think anyone would be opposed to a fix. #477 is part of the move away from a libcuspatial->libcudf dependence. Fixing the cuspatial->cudf Python dependence would take a lot more work and is probably not going to happen any time in the near to intermediate term.

[vyasr]

@gpucibot merge