Upgrade third_party/protobuf to v3.14.0

[jtattermusch]

No description provided.

[jtattermusch]

Some of the failures might have already been investigated as part of #24723.

[jtattermusch]

Problems that likely need to be solved (the rest looks like preexisting issues)

Python27 on windows:
https://source.cloud.google.com/results/invocations/1ff03886-f487-4466-9149-67aca05767e8/targets/github%2Fgrpc/tests

Python bazel tests:
https://source.cloud.google.com/results/invocations/0fda9ba0-4fd9-4a50-9af1-41cc753f04d3/log

Ruby native gem on macos:
https://source.cloud.google.com/results/invocations/7a195775-9293-4177-a79e-370af526a00f/targets/github%2Fgrpc/tests

@gnossen @lidizheng can you take a look at the python-related issues?

[lidizheng]

C:\tools\msys64_win7\mingw64\bin\gcc.exe -mdll -O -Wall -DWIN32_LEAN_AND_MEAN=1 -DMS_WIN64=1 -I. -Igrpc_root -Igrpc_root\include -Ithird_party\protobuf\src -IC:\Python27\include -IC:\Python27\PC -c third_party\protobuf\src\google\protobuf\util\internal\json_escaping.cc -o build\temp.win-amd64-2.7\Release\third_party\protobuf\src\google\protobuf\util\internal\json_escaping.o -std=c++11 -D_ftime=_ftime64 -D_timeb=__timeb64 -D_hypot=hypot
C:\tools\msys64_win7\mingw64\bin\gcc.exe -mdll -O -Wall -DWIN32_LEAN_AND_MEAN=1 -DMS_WIN64=1 -I. -Igrpc_root -Igrpc_root\include -Ithird_party\protobuf\src -IC:\Python27\include -IC:\Python27\PC -c third_party\protobuf\src\google\protobuf\compiler\cpp\cpp_map_field.cc -o build\temp.win-amd64-2.7\Release\third_party\protobuf\src\google\protobuf\compiler\cpp\cpp_map_field.o -std=c++11 -D_ftime=_ftime64 -D_timeb=__timeb64 -D_hypot=hypot
In file included from third_party\protobuf\src\google\protobuf\util\message_differencer.cc:50:0:
third_party\protobuf\src/google/protobuf/map_field.h: In constructor 'constexpr google::protobuf::internal::MapFieldBase::MapFieldBase(google::protobuf::internal::ConstantInitialized)':
third_party\protobuf\src/google/protobuf/map_field.h:336:37: error: call to non-constexpr function 'google::protobuf::internal::WrappedMutex::WrappedMutex()'
         state_(STATE_MODIFIED_MAP) {}
                                     ^

The Python compilation error seems caused by the new ProtoBuf.

---

The Bazel test failure seems caused by namespace packaging disfunction. The namespace package should be a part of ProtoBuf Python package, which we installed via pip, I'm not sure why upgrade our third_party ProtoBuf will cause that. Is it failing consistantly?

[gnossen]

The build failure looks like a legitimate issue in protobuf that they've already fixed on master. The error indicates that the WrappedMutex constructor is not constexpr, which it isn't on 3.14.0. Some compilers are lenient on this and will add the constexpr for you if possible. Our Windows compiler appears not to be one of them.

I think our two options are:

• Upgrade the compiler to something more lenient on constexpr marking.
• Backport this fix to v3.14.0

P.S.: I'm secretly rooting for the backport, because that gets us one digit closer to this being the pi release.

[jtattermusch]

FTR the python bazel build failure is:

==================== Test output for //src/python/grpcio_tests/tests_aio/interop:local_interop_test:
Traceback (most recent call last):
  File "/root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/sandbox/processwrapper-sandbox/2815/execroot/com_github_grpc_grpc/bazel-out/k8-fastbuild/bin/src/python/grpcio_tests/tests_aio/interop/local_interop_test.runfiles/com_github_grpc_grpc/src/python/grpcio_tests/tests_aio/interop/local_interop_test.py", line 24, in <module>
    from tests_aio.interop import methods
  File "/root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/sandbox/processwrapper-sandbox/2815/execroot/com_github_grpc_grpc/bazel-out/k8-fastbuild/bin/src/python/grpcio_tests/tests_aio/interop/local_interop_test.runfiles/com_github_grpc_grpc/src/python/grpcio_tests/tests_aio/interop/methods.py", line 29, in <module>
    from google import auth as google_auth
ImportError: cannot import name 'auth'
================================================================================
INFO: From Linking tools/distrib/python/grpcio_tools/grpc_tools/_protoc_compiler.so:
clang-12: warning: '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead
INFO: From Linking tools/distrib/python/grpcio_tools/libprotoc_lib.so:
clang-12: warning: '-fuse-ld=' taking a path is deprecated. Use '--ld-path=' instead
FAIL: //src/python/grpcio_tests/tests_aio/status:grpc_status_test (see /root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/execroot/com_github_grpc_grpc/bazel-out/k8-fastbuild/testlogs/src/python/grpcio_tests/tests_aio/status/grpc_status_test/test.log)
INFO: From Testing //src/python/grpcio_tests/tests_aio/status:grpc_status_test:
==================== Test output for //src/python/grpcio_tests/tests_aio/status:grpc_status_test:
Traceback (most recent call last):
  File "/root/.cache/bazel/_bazel_root/d2dc70c3d9da3fab488ba0dcbbd35051/sandbox/processwrapper-sandbox/2955/execroot/com_github_grpc_grpc/bazel-out/k8-fastbuild/bin/src/python/grpcio_tests/tests_aio/status/grpc_status_test.runfiles/com_github_grpc_grpc/src/python/grpcio_tests/tests_aio/status/grpc_status_test.py", line 22, in <module>
    from google.rpc import code_pb2, error_details_pb2, status_pb2
ModuleNotFoundError: No module named 'google.rpc'
================================================================================

[jtattermusch]

they've already fixed on master

Looks like that fix is coming from the internal codebase (cl/341698875)
@acozzette can we backport cl/341698875 into 3.14.x branch?

[acozzette]

@jtattermusch I just sent out protocolbuffers/protobuf#8115 to pull that fix into 3.14.x.

[jtattermusch]

@stanley-cheung Ideally protobuf should be upgraded before cutting the 1.35.x branch (according to our release process).

[stanley-cheung]

@stanley-cheung Ideally protobuf should be upgraded before cutting the 1.35.x branch (according to our release process).

Sorry I missed this. Should have made this a release blocker. What's the remedy now? Should we also backport this to the v1.35.x branch?

[jtattermusch]

@stanley-cheung Ideally protobuf should be upgraded before cutting the 1.35.x branch (according to our release process).

Sorry I missed this. Should have made this a release blocker. What's the remedy now? Should we also backport this to the v1.35.x branch?

I created #25131 hopefully all the tests pass.

[jtattermusch]

Superseded by #25183 (which brings in #25131 from v1.35.x)