Fix ObjectOutput.result1 corruption in RMW retries

[kevin-montrose]

A number of "object" commands mutate ObjectOutput.result1 in response to a InitialUpdater call.

However these calls can be retried under contention, so any mutation that assumes an initial value (typically 0) will produce incorrect results. I've audited uses of result1 and fixed all the places where this can happen.

This fixes #1833

I did a separate pass through StringOutput and UnifiedOutput, and I think we're all fine there.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[mgravell]

I can't opine on any missing cases, but the ones shown make sense. Kudos for looking wider than the initial report.

[mgravell]

Genuine question from a mostly-outside-observer who doesn't know anything about the complexity involved: is this amenable to unit testing? Is there some reusable setup/invoke/observe test loop that could be applied to all the operation implementations in a generic way simulating both success and failure (retry), to prevent recurrence/oversight?

[kevin-montrose]

Genuine question from a mostly-outside-observer who doesn't know anything about the complexity involved: is this amenable to unit testing? Is there some reusable setup/invoke/observe test loop that could be applied to all the operation implementations in a generic way simulating both success and failure (retry), to prevent recurrence/oversight?

I was thinking on that this morning - it's tricky because the logic is actually split between ObjectSessionFunctions, GarnetObjectBase, and the data type classes. ObjectSessionFunctions is the hard part there, as we'd ways to manufacture consistent-ish LogRecords.

If we run into more of these (I think I got them all) or similar issues we could harden the code by refactoring to either a) add a Reset() method to TOutput or b) introduce a TOutputFactory type to get fresh TOutputs on retries.