etl: acknowledge completed direct puts

[chanu1406]

Go webserver and target-side changes for #334

• target returns 204 with Ais-Direct-Put-Complete and Ais-Direct-Put-Length after a successful direct PUT
• Go ETL webservers propagate the marked ack, including a stored length of 0
• markerless responses keep the existing handling unchanged, for targets that predate the marker

I have verified on a 3 node KinD cluster with 2 targets, with a 2 stage Go echo pipeline built from this branch.

• the target returned the marked 204 with the exact stored length
• the intermediate stage propagated the marker and length
• length 0 worked end to end, and produced a correct empty object
• same-target responses stayed on the existing unmarked 200 content path
• all 9 destination objects present; sampled checksums (including the empty object) matched the source

[Nahemah1022]

@chanu1406 Thanks for the contribution! After revisiting all the pipeline paths, I realized we missed an important case in the completion-marker design we discussed.

The marker works when the pipeline ends with a direct PUT to a different destination target. However, for pipelined inline transforms or offline transforms whose destination is local, the final ETL stage returns output instead. The preceding ETL stage then receives an empty 200 without the completion marker and falls back to legacy handling, where the response can be misclassified as a completed direct PUT. Consequently, the valid empty output is discarded, and AIS skips returning or storing it because it incorrectly believes the destination has already stored the object.

I’m going to take a little more time to think through the response contract and make sure it robustly covers every pipeline path. In the meantime, if you see a clean way to address these cases without complicating the response handling or relying on HTTP framing, please feel free to propose it. I’d be happy to review the design with you and refine it together. Thanks again for working through this!

[chanu1406]

@Nahemah1022 thanks for reviewing, you're right about both those cases. There is still ambiguity with the legacy fallback.

I agree that the response contract should be thought through further, covering all cases. If I have anything to add I will let you know