Add compile time check to ensure the counting_iterator type in counting_transform_iterator fits in size_type

[mhaseeb123]

Description

This PR adds a compile time check to enforce that the start argument to cudf::detail::counting_transform_iterator, which is used to determine the type of counting_iterator, is of a type that fits in int32_t (aka size_type). The PR also modifies the instances of counting_transform_iterator that need to work with counting_iterators of type > int32_t to manually created counting_transform_iterators using thrust.

More context in this comment.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[vuule]

I think this is a good change, even if it is a bit breaking. Reminds me of the surprising return value type in std::accumulate, which is determined using the initial value, rather than the type that the binaryOp takes or returns.
I think this is worth a PSA, to make sure the size_type conversion is not actually a desired feature.

[davidwendt]

The intention was to use the transform iterator with thrust and since we only use the 32-bit bound thrust/cub calls, this was a good reminder/check not to use more than size_type values with this iterator. Also, the predicate was usually addressing column rows or similar features which is limited to size_type as well.
I feel this may cause more problems and give the appearance that the iterator supports more than it should in practice. It is a simple wrapper on the thrust::make_transform_iterator so if there is a real need to use more than 32-bit values, just use the thrust one instead. We could document this better as well.

[mhaseeb123]

The intention was to use the transform iterator with thrust and since we only use the 32-bit bound thrust/cub calls, this was a good reminder/check not to use more than size_type values with this iterator. Also, the predicate was usually addressing column rows or similar features which is limited to size_type as well.

I see. Yeah it makes sense in that case.

I feel this may cause more problems and give the appearance that the iterator supports more than it should in practice. It is a simple wrapper on the thrust::make_transform_iterator so if there is a real need to use more than 32-bit values, just use the thrust one instead. We could document this better as well.

I agree but perhaps we should add some compile-time check as well in addition to documenting it?

[kingcrimsontianyu]

Lgtm! Left a comment about using static_assert.

[mhaseeb123]

/merge