feat(Query, ChangeFeed): Provide ability to specify max Request Charge budget

[bartelink]

Is your feature request related to a problem? Please describe.
When running a changefeed, or other query-based polling that's secondary to the core processing, the core mechanism the API provides is to have responses/continuations grouped by number of items returned. When items vary in size, the load a consumer places on the Container is subject to spikes and inconsistency.

Describe the solution you'd like
When items vary in size, being able to express the limit as a maximum RU cost you're willing to incur for a given query (in lieu of specifying a MaxItems that's guaranteed to be within the limit) more directly expresses the need.

Describe alternatives you've considered
The main workaround to date is to use an artificially low MaxItems in the query, and then pause querying based on a leaky bucket. However esp with CFP, that a) doesnt provide the best throughput and b) relies on #616

Additional context
Being able to express the constraint at the CosmosDB core request level was covered in a conference call some time back and agreed to in principle. Raising it here as I believe this to be a very important facility in general, as it allows in a much broader set of use cases for subscriptions and/or syncing pipelines.

[timsander1]

Hi @bartelink , this use case makes sense. Thank you for submitting this feedback. We'll consider this in our planning during the upcoming six month period, but as of now, this is unplanned.

[bartelink]

Still looking for this, 3 years on (reminded of it by https://devblogs.microsoft.com/cosmosdb/introducing-priority-based-execution-in-azure-cosmos-db-preview, which would slot in alongside nicely in terms of smoothing out the effects of competing workflows)