request: return ListenableFutures in PubSub async methods rather than bare Futures #1148
Description
The com.google.cloud.pubsub.PubSub interface defines async operations which return java.util.concurrent.Future values.
For anyone who uses the ListenableFuture concept from Guava (or CompletableFutures in Java 8), these Futures have to be adapted into ListenableFutures by spawning a thread that blocks on the Future.get() return.
It would be much more convenient if the Futures returned from PubSub were actually ListenableFuture instances (even if the interface did not define the return value to be ListenableFuture) - then it would not be necessary for users to block one thread per future they wish to adapt into a ListenableFuture.
For instance, internally PubSubImpl.pullAsync(final String subscription, int maxMessages) is implemented by using the listenable-like com.google.cloud.pubsub.spi.PubSubRpc.PullFuture and attaching callbacks to it, but the returned Future is an anonymous subclass of Future created by Futures.lazyTransform(..).
Is it a conscious decision to avoid using ListenableFutures in the interfaces defined in gcloud-java-pubsub and other clients?
It seems like the com.google.cloud.pubsub.spi layer has access to ListenableFuture instances via the generated grpc client code (like subscriberApi.acknowledgeCallable().futureCall(request)) but then these are discarded in the PubSubImpl layer.