[ROCm][MIGraphX] for googletest dep, set OVERRIDE_FIND_PACKAGE

[jeffdaily]

Otherwise, an unsupported version of gtest/gmock will be found at /opt/conda/include for ROCm builds. Though this issue was initially found for ROCm builds, the issue is generic. onnxruntime requires a specific version of googletest and should not rely on locating googletest using find_package.

The ROCm error was:

In file included from /opt/conda/include/gmock/gmock-spec-builders.h:75,
                 from /opt/conda/include/gmock/gmock-generated-function-mockers.h:47,
                 from /opt/conda/include/gmock/gmock-function-mocker.h:39,
                 from /opt/conda/include/gmock/gmock.h:61,
                 from /stage/onnxruntime/onnxruntime/test/util/test_utils.cc:17:
/opt/conda/include/gmock/gmock-matchers.h: In instantiation of ‘bool testing::internal::PointwiseMatcher<TupleMatcher, RhsContainer>::Impl<LhsContainer>::
MatchAndExplain(LhsContainer, testing::MatchResultListener*) const [with LhsContainer = const gsl::span<const float>&; TupleMatcher = testing::internal::
FloatingEq2Matcher<float>; RhsContainer = gsl::span<const float>]’:
/opt/conda/include/gmock/gmock-matchers.h:2303:10:   required from here
/opt/conda/include/gmock/gmock-matchers.h:2312:48: error: no type named ‘const_iterator’ in ‘testing::internal::PointwiseMatcher<testing::internal::
FloatingEq2Matcher<float>, gsl::span<const float> >::Impl<const gsl::span<const float>&>::LhsStlContainer’ {aka ‘class gsl::span<const float>’}

[TedThemistokleous]

ping @PeixuanZuo @cloudhan we need this for both ROCm and MIGraphX EPs

[jeffdaily]

@cloudhan and @PeixuanZuo please review. This issue will soon affect ROCm azure pipelines, if not already.

[cloudhan]

/azp run Windows ARM64 QNN CI Pipeline,Windows CPU CI Pipeline,Windows GPU CI Pipeline,Windows GPU TensorRT CI Pipeline,onnxruntime-binary-size-checks-ci-pipeline,orttraining-linux-ci-pipeline,orttraining-linux-gpu-ci-pipeline,orttraining-ortmodule-distributed

[azure-pipelines]

Azure Pipelines successfully started running 8 pipeline(s).

[cloudhan]

/azp run Linux CPU CI Pipeline,Linux CPU Minimal Build E2E CI Pipeline,Linux GPU CI Pipeline,Linux GPU TensorRT CI Pipeline,Linux OpenVINO CI Pipeline,Linux QNN CI Pipeline,MacOS CI Pipeline,ONNX Runtime Web CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 8 pipeline(s).

[snnn]

Generally speaking, building onnxruntime from source on Linux should be done in docker containers which doesn't have extra packages, and you should not use conda unless that you are building a package that is just for conda(won't be compatible with CPython and packages in pypi.org). Otherwise you should disable the find package feature from build command line for all such external projects, not just gtest.
We need to reconsider it. Because:
1.This change is too specific for RoCM, but it impacts everyone who integrates ORT to their package management system(like the Linux distros)
2. Googletest depends on abseil and many other things. They should all come from the same source. Either you disable find_package for all of them, or none. Otherwise the inconsistence would cause incompatible package versions being used.

Because not every OSS's cmake file could do version matching correctly and exactly, the best practice is to make the build environment clean, not have extra packages, minimize dependencies. Compared to the other build systems like Bazel, CMake is easy to use and but it is not as powerful as you may wish.

[cbourjau]

@jeffdaily Do you have more information about the build failure?

@snnn I noticed that this change made it into the 1.16.0 release candidate. This change seems pretty heavy-handed and breaks or at least further complicates packaging for nixpkgs and probably many other package managers. Things used to work with the same gtest version for the 1.15.1 release without the change of this PR. Is it really necessary or do yo maybe see some way to work around it?

[snnn]

From my perspective, it is not needed and harmful. If someone has the need to disable find_package, he/she can do it globally for all dependencies we have.

[snnn]

#17523