PubSub Source using Unary Pull

[istreeter]

The previous implementation of the PubSub Source was a wrapper around Subscriber provided by the 3rd-party pubsub sdk. That Subscriber is a wrapper around a lower-level GRPC stub. It used the "Streaming Pull" GRPC method to fetch messages from PubSub.

This commit abandons using the Subscriber and instead wraps the GRPC stub directly. It uses the "Unary Pull" GRPC method to fetch messages from PubSub.

We found that "Unary Pull" alleviates a problem in which PubSub occasionally re-delivers the same messages, causing downstream duplicates. The problem happened especially in apps like Lake Loader, which builds up a very large number of un-acked messages and then acks them all in one go at the end of a timed window.

Compared with the previous Source implementation it has these differences in behaviour:

• Previously, the 3rd-party Subscriber managed ack extensions (a.k.a. modifying ack deadlines). Ack extension periods were adjusted dynamically according to runtime heuristics of message processing times. Whereas in this new Source, the ack extension period is a fixed configurable period.
• Previously, the Subscriber periodically mod-acked all unacked messages currently held in memory. Whereas the new Source only mod-acks messages when they are approaching their ack deadline. This is an improvement for apps like Lake Loader which might have a very large number of outstanding unacked messages.
• Unary Pull has slightly worse latency compared to Streaming Pull. I consider this ok for common-streams apps, where the latency caused by the Source is negligible compared to other latencies in the app.
• Arguably, "Unary Pull" is a neater fit (less hacky) for a common-streams Source. Now, we simply pull a batch when a batch is needed.