Bump grpc java to 1.31.1 too

[dmivankov]

Between 1.26.0 and 1.31.1 grpc-java had changes including

• bugfixes
• netty 4.1.42.Final -> 4.1.48.Final (we're already on 4.1.48.Final)
• guava 28.1-android -> 29.0-android (we're already on 29.0-android)
• google auth 0.18.0 -> 0.20.0 (we're still on 0.17.1)
• protobuf 3.11.0 -> 3.12.0 (not a runtime dependency)

Transitively there's also dependency updates

• google-http-client 1.30.1 -> 1.33.0 (we're still on 1.22.0)
• jackson-core .. -> 2.10.0 (we're at 2.8.6)
  and likely more

Quick look over changelogs doesn't reveal big breakages, so hopefully
this the update is compatible with other bootstrap jars

[meteorcloudy]

Nice, thanks! Can you also split this PR so that we can merge it?

[dmivankov]

@meteorcloudy I'm not really sure how to properly split this PR. I'm assuming it should be

• add third_party changes for new version, but effectively don't change anything, just add new targets&files under //third_party/grpc
• apply changes outside of //third_party to use new version
• remove previous version from //third_party/grpc

But there are few issues with that

• there are mentions of "//third_party/grpc:grpc-jar", "//third_party/grpc:bootstrap-grpc-jars", "//third_party/grpc:grpc-java-plugin" outside third_party, they all need to be versioned (not a big deal imo, but exposes version, unless we can alias it all in WORKSPACE once)
• //third_party/grpc/compiler is a single directory, so need to have compiler and compiler-1.31.1
• load("//third_party/grpc:build_defs.bzl", "java_grpc_library") is used outside of third_party, but it depends on grpc version so build_defs.bzl or java_grpc_library macro needs to be versioned too (a matter of exposing version to WORKSPACE or BUILD files)
• load("//third_party/grpc:build_defs.bzl", "java_grpc_library") is used in //third_party/googleapis and //third_party/remoteapis, which means now we need to transitively split versions there as well and probably do more transitive versions...

So my question is, do we really need to split it or passing PR build is good enough indication? Or is it ok to have 3 steps like following

• do changes in //third_party that may already (partially of fully) affect main targets outside third_party
• do changes outside //third_party that will finalize the switch
• do cleanup in //third_party if needed

Those 3 for this PR will probably collapse into

• add 1.31.1 jars to third_party, use them by default (so except for //:scripts/bootstrap/compile.sh), use 1.31.1 java_plugin. This will effectively update grpc java 1.31.1 (not 100% sure here, is bootstrap bazel used to compile release bazel or is bootstrap bazel released directly?)
• update scripts/bootstrap/compile.sh to use 1.31.1 jars
• remove 1.26.0 jars from third_party

[meteorcloudy]

• add 1.31.1 jars to third_party, use them by default (so except for //:scripts/bootstrap/compile.sh), use 1.31.1 java_plugin. This will effectively update grpc java 1.31.1 (not 100% sure here, is bootstrap bazel used to compile release bazel or is bootstrap bazel released directly?)
• update scripts/bootstrap/compile.sh to use 1.31.1 jars
• remove 1.26.0 jars from third_party

Yes, this sounds good to me. What I did when upgrading the grpc jars from 1.20.0 to 1.26.0 was using a fallback, then add and delete the jars in the same commit. , which ensures the bootstrap also uses the same version of grpc jars. But I don't really mind the small inconsistency in a short period of time.

[dmivankov]

Split into
#12255
#12256
#12257

[dmivankov]

merged by linked parts