kvcoord: assert on unexpected resume spans in write buffer

We could handle the resume span here, but it is very hard to test that
handling since we have another layer of assertions earlier in the code.
Instead, we add an additional assertion rather than handling an event we
don't expect to happen.

Epic: none
Release note: None

Author: stevendanna

pkg/kv/kvclient/kvcoord/txn_interceptor_write_buffer.go

@@ -1377,6 +1377,11 @@ func (rr requestRecord) toResp(
 	var ru kvpb.ResponseUnion
 	switch req := rr.origRequest.(type) {
 	case *kvpb.ConditionalPutRequest:
+		if !rr.stripped && br.GetInner().Header().ResumeSpan != nil {
+			return kvpb.ResponseUnion{},
+				kvpb.NewError(errors.AssertionFailedf("unexpected non-nil ResumeSpan for ConditionalPutRequest"))
+		}
+
 		// Evaluate the condition.
 		evalFn := mvcceval.MaybeConditionFailedError
 		if twb.testingOverrideCPutEvalFn != nil {
@@ -1390,11 +1395,6 @@ func (rr requestRecord) toResp(
 			// We only use the response from KV if there wasn't already a
 			// buffered value for this key that our transaction wrote
 			// previously.
-			// TODO(yuzefovich): for completeness, we should check whether
-			// ResumeSpan is non-nil, in which case the response from KV is
-			// incomplete. This can happen when MaxSpanRequestKeys and/or
-			// TargetBytes limits are set on the batch, and SQL currently
-			// doesn't do that for batches with CPuts.
 			val = br.GetInner().(*kvpb.GetResponse).Value
 		}
 
@@ -1425,12 +1425,12 @@ func (rr requestRecord) toResp(
 		twb.addToBuffer(req.Key, req.Value, req.Sequence, req.KVNemesisSeq, dla)
 
 	case *kvpb.PutRequest:
+		if !rr.stripped && br.GetInner().Header().ResumeSpan != nil {
+			return kvpb.ResponseUnion{},
+				kvpb.NewError(errors.AssertionFailedf("unexpected non-nil ResumeSpan for PutRequest"))
+		}
+
 		var dla *bufferedDurableLockAcquisition
-		// TODO(yuzefovich): for completeness, we should check whether
-		// ResumeSpan is non-nil if we transformed the request, in which case
-		// the response from KV is incomplete. This can happen when
-		// MaxSpanRequestKeys and/or TargetBytes limits are set on the batch,
-		// and SQL currently doesn't do that for batches with Puts.
 		if rr.transformed && exclusionTimestampRequired {
 			dla = &bufferedDurableLockAcquisition{
 				str: lock.Exclusive,