OkHttp is incompatible with newer C-core binaries

[ejona86]

As reported by grpc/grpc#11258. This is caused by grpc/proposal#19 and a bug in the OkHttp transport that doesn't ignore unknown settings frames (as required by the HTTP/2 spec).

It's unclear how this wasn't caught in the integration tests.

[makdharma]

@ericgribkoff to test in the Android interop he's working on.

[ejona86]

We don't run okhttp interop externally (full cross-product testing), but we do internally. We think the breaking change was delayed being brought internally for long enough that it was released without the test having failed yet.

[ericgribkoff]

Created #3036 to address this, although I'm not sure what restrictions we have with modifying the third_party okhttp code. The bug was noticed on OkHttp3 (square/okhttp#2299), although I believe their fix still fails for the experimental settings ids used by C++.

We don't run okhttp interop externally (full cross-product testing), but we do internally. We think the breaking change was delayed being brought internally for long enough that it was released without the test having failed yet.

This appears to have been the case.

I did some work to add a gRPC Java OkHttp client to the grpc/grpc interop test suite, but encountered some issues with getting our test certificates working with OkHttp. I will look further into this tomorrow, as it seems like we definitely should be testing OkHttp clients as part of our external interops, to (help) avoid issues like this.

[ejona86]

This was fixed in #3036