Remove public gtest dependency from libcudf conda package

[robertmaynard]

Description

Reworks the cudftestutil and dependency chain to remove the public gtest dependency in libcudf conda package.
The libcudftestutil was previously made static due to issues using a static system GTest that wasn't build with fPIC. Using a GTest from rapids-cmake which is built with fPIC enabled, removes this restriction and allows us to remove the public depedency.

Some notes:

• We need to align all of RAPIDS C++ projects on static GTest from rapids-cmake
• None of the compiled components / classes of libcudftestutils publically depend on GTest
• Two of the libcudftestutils header only components bring include gtest. Since these headers aren't required to be used we are going to consider them optional.
• Therefore using these optional libcudftestutils header will require downstream users to bring in GTest.

Fixes #13381
Contributes to rapidsai/build-planning#32

Checklist

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

[bdice]

I merged the upstream to get CI unblocked.

[vyasr]

While I think this change is already safe across the rest of RAPIDS (rapidsai/build-planning#32), I suspect we need to do a bit more work in cudf. Specifically, I think we have to address #13381. Currently libcudftestutil.a exports a public dependency on GTest. Granting that it is already a static library, that still means that consumers of it will see APIs that have use gtest. What happens if someone tries to link against libcudftestutil.a, but has compiled their code using a different version of gtest? Won't that result in incompatible binaries?

In practice the only use case I'm aware of is cuspatial, which uses rapids-cmake and we control, so it's probably not a serious issue, but unless I'm misunderstanding it is a real potential issue that is worth trying to resolve before merging this.

[robertmaynard]

While I think this change is already safe across the rest of RAPIDS (rapidsai/build-planning#32), I suspect we need to do a bit more work in cudf. Specifically, I think we have to address #13381. Currently libcudftestutil.a exports a public dependency on GTest. Granting that it is already a static library, that still means that consumers of it will see APIs that have use gtest. What happens if someone tries to link against libcudftestutil.a, but has compiled their code using a different version of gtest? Won't that result in incompatible binaries?

In practice the only use case I'm aware of is cuspatial, which uses rapids-cmake and we control, so it's probably not a serious issue, but unless I'm misunderstanding it is a real potential issue that is worth trying to resolve before merging this.

This is a great point. Using a static GTest with libcudf would mean that conda consumers would be forced to never have GTest in the conda env. I agree with you that this is not a desired outcome, and it looks like we can't move over to a static GTest for libcudf without first splitting the testing component into a separate conda package.

I am going to close this PR in that case, as that is out of scope of this change

[robertmaynard]

Re-opnening this PR since we realized that by always building our own GTest, we don't need to worry about linking to a static system GTest which wasn't built with fPIC.

[bdice]

Re-reviewed on request. Looks good.

[vyasr]

/merge

[robertmaynard]

This is not needed now that we use a GTest version dowloaded via rapids-cmake. In addition the logic was incorrectly triggering on the devcontainer builds due to a system installed GTest causing us to break the internals of GTest