[C++] protobuf 3.7 defines EXPECT_OK that clashes with Arrow's macro

[asfimport]

This fails for me with the following error:

/home/travis/build/xhochy/arrow/cpp/src/arrow/flight/test-util.cc
In file included from /home/travis/build/xhochy/arrow/cpp-toolchain/include/google/protobuf/util/type_resolver.h:39:0,
                 from /home/travis/build/xhochy/arrow/cpp-toolchain/include/google/protobuf/util/json_util.h:37,
                 from /home/travis/build/xhochy/arrow/cpp-toolchain/include/grpcpp/impl/codegen/config_protobuf.h:70,
                 from /home/travis/build/xhochy/arrow/cpp/src/arrow/flight/customize_protobuf.h:23,
                 from /home/travis/build/xhochy/arrow/cpp/src/arrow/flight/protocol-internal.h:20,
                 from /home/travis/build/xhochy/arrow/cpp/src/arrow/flight/internal.h:23,
                 from /home/travis/build/xhochy/arrow/cpp/src/arrow/flight/test-util.cc:35:
/home/travis/build/xhochy/arrow/cpp-toolchain/include/google/protobuf/stubs/status.h:111:0: error: "EXPECT_OK" redefined [-Werror]
 #define EXPECT_OK(value) EXPECT_TRUE((value).ok())
 
In file included from /home/travis/build/xhochy/arrow/cpp/src/arrow/ipc/test-common.h:35:0,
                 from /home/travis/build/xhochy/arrow/cpp/src/arrow/flight/test-util.cc:30:
/home/travis/build/xhochy/arrow/cpp/src/arrow/testing/gtest_util.h:80:0: note: this is the location of the previous definition
 #define EXPECT_OK(expr)         \
 
cc1plus: all warnings being treated as errors

I would workaround this by renaming our EXPECT_OK to ARROW_EXPECT_OK.

Reporter: Uwe Korn / @xhochy
Assignee: Uwe Korn / @xhochy

_{Note: This issue was originally created as ARROW-4760. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
Is there an upstream bug report? They shouldn't be exporting a macro named like that

[asfimport]

Uwe Korn / @xhochy:
This has been there for over 4 years now. This error simply popped up as I didn't include protobuf headers using include(SYSTEM …). Using SYSTEM will let the compiler ignore all warnings in third-party headers. We have been using this for now and I'll also switched to using this now in my CMake refactor as there is an awful lot of warnings in the thirdparty headers.

[asfimport]

Uwe Korn / @xhochy:
Resolved by PR #3688