Similar to #46758, but more important in the places where it is applicable.

deleteRangeNode is an optimization of deleteNode for executing DELETE statements in a single pass. It avoids a ScanRequest followed by a DeleteRequest, opting instead for a DeleteRangeRequest with the ReturnKeys option enabled. This is a nice win.

However, it conflates the idea of a single-pass write operation with that of a ranged write operation, probably because DeleteRequest itself does not have a ReturnKeys option or any other way to indicate whether it deleted an existing row or not. As a result, it comes with more trade-offs than strictly necessary. These trade-offs include everything discussed in #46758. They also include two other even more serious negatives:

• ranged KV writes (DeleteRangeRequest) cannot be pipelined because an enumeration of the intents that they will leave cannot be known ahead of time. They must therefore perform evaluation and replication synchronously.
• ranged KV writes (DeleteRangeRequest) result in ranged intent resolution, which is less efficient, especially until we re-enable time-bound iterators.

We should explore issuing point DeleteRequest operations with a similar fast-path to the one deleteRangeNode contains in cases where the set of keys to be deleted is enumerable. To support this, DeleteResponse will need to indicate whether the specified key was deleted or not.

This comes up in TPC-C's delivery transaction, which issues a statement like the following. In traces, we see that the inability to pipeline these writes slows down the entire delivery transaction substantially.

DELETE FROM new_order
      WHERE no_w_id = 0
        AND (no_d_id, no_o_id)
            IN (
                    (3:::INT8, 2484:::INT8),
                    (5:::INT8, 2484:::INT8),
                    (4:::INT8, 2484:::INT8),
                    (8:::INT8, 2484:::INT8),
                    (9:::INT8, 2484:::INT8),
                    (1:::INT8, 2484:::INT8),
                    (10:::INT8, 2484:::INT8),
                    (2:::INT8, 2484:::INT8),
                    (6:::INT8, 2484:::INT8),
                    (7:::INT8, 2484:::INT8)
                );

Jira issue: CRDB-3818