fix(snuba commit log): Modify Rust consumer to produce next message offset to Snuba commit log

[shashjar]

https://linear.app/getsentry/issue/ID-1390/investigate-end-to-end-slo-burn-in-geicogs

Fixes a bug in the Snuba Rust consumer. When producing commit log entries, the Rust consumer currently uses the current offset (the offset of the latest event which has been persisted to CH). By contrast, the Python consumer uses the next offset (the offset of the first event which has not yet been persisted to CH).

Sentry-side, the SynchronizedConsumer implementation blocks if message.offset >= remote_offset. It therefore expects the remote_offset it got from the Snuba commit log to be the offset of the next event, not the current one.

This off-by-one bug has been causing increased event latency in the Geico and Goldman Sachs regions since we increased the number of partitions in the PPF for INC-2007, since lone events spend more time waiting in sparse partitions for another event to enter (SLO burn, increased PPF consumer latency).

This PR brings the Rust consumer into line with the Python consumer and the SynchronizedConsumer's expectations.

More context / discussion in this Slack thread

[shashjar]

Would like to confirm two things with EAP:

1. Were these offset semantics intended behavior for any reason?
2. Are there any consumers of Snuba commit log entries other than the SynchronizedConsumer implementation (post-process forwarder consumers)? If so and they rely on the current offset semantics, we may have to rethink our approach here.

[shashjar]

For (2), I believe the only other consumer of the Snuba commit log is the subscription consumer. It looks to me like the subscription consumer cares only about offset intervals (not absolute values), so I think it should be unaffected by the change in this PR (except for maybe immediately after rollout?).