cronet: use reflection to load and invoke experimental APIs in ExperimentalBidirectionalStream.Builder

[voidzcy]

grpc-cronet relies on the feature of cronet's BidirectionalStream, which is created by ExperimentalCronetEngine#newBidirectionalStreamBuilder(...) (returns a ExperimentalBidirectionalStream.Builder). Since it's "experimental", we want to avoid calling APIs on ExperimentalBidirectionalStream.Builder.

We've removed grpc-cronet APIs that depends on ExperimentalBidirectionalStream.Builder's APIs and only allow restricted internal usages. External users should have no chance calling them and result in breakage. Now we switch to load those unstable ExperimentalBidirectionalStream.Builder APIs and invoke them through reflection at runtime.

The three potentially unstable APIs are setTrafficStatsTag, setTrafficStatsUid and addRequestAnnotation. For now, we handle method not found or method invocation exceptions by logging a warning and skip calling them. This handling should be tolerable and won't cause severe breakage. But later, we may choose to fail the RPC if failing to call those methods at runtime.

I'd expect the class ExperimentalBidirectionalStream.Builder to be there for stable as it is the return type of ExperimentalCronetEngine#newBidirectionalStreamBuilder(...). So we would not need to load ExperimentalBidirectionalStream.Builder class through reflection while only for invoking those less likely stable methods.

[ejona86]

The getMethod() is the slowest part of reflection. We should save the result and re-use it across invoke()s.

Since we really aren't expecting this to ever fail (because the app will be shipping cronet itself), then performance for the failure case probably doesn't matter much. That means we could just re-call getMethod() each time if it is failing, and so we'd have an exception each time as well. We'd only need a single field to hold each Method.

We can use a lock or volatile to protect the Method field. It doesn't matter to me which.

[voidzcy]

Done.