IssueTracker

Problem you have encountered:
Right now the Go client (not sure of others) supports a MaxOutstandingMessages knob but it's communicated to the server on a per-StreamingPull-stream basis (which is based on a separate NumGoroutines knob) which means that the server-side has a much higher max than the client. This results in too many messages being sent to the client and they end up sitting in flow control waiting potentially longer than MaxExtension and expiring.

What you expected to happen:
Ideally there would be a dynamic number of streams such that if the rate is less than 10MB/s then there's no need for more than one stream.

Also, I could see there being a dynamic client-side max as well that might be based on something like the rate of non-expiring messages.

Steps to reproduce:
1. Using the Go Client set MaxOutstandingMessages=x and NumGoroutines=y
2. Observe server sending x*y messages instead of just y and messages sit in flow control in the client

Other information (workarounds you have tried, documentation consulted, etc):
This is related to https://github.com/googleapis/google-cloud-go/issues/9727