More precise ack batch calculation for subscriber

[dbolduc]

We assume some conservative upper limit on the number of ack IDs that fit in an AcknowledgeRequest and ModifyAckDeadlineRequest. It seems that ack IDs are of variable length¹. As @feywind points out, it would be more precise to measure the size of the protobuf request as we fill it, and use that to determine when a batch is full.

We would probably modify our Leases class to keep track of the to_ack / to_nack size on Leases::add(). Gemini tells me we should add 3 + ack_id.len(), because the protobuf encoding for a string takes 3 bytes. We could cut off the request size at like 500 kB, and probably fill more ack IDs in a batch than we are doing now.

This might have a slight performance bump for very high throughput applications.

Footnotes

1. maybe a function of the subscription length? ↩

[suzmue]

Related on the publishing side: #3963 (and there is already an implementation for estimating proto message sizes for these batch calculations in the publisher that we should consider sharing)