sql: optimize UPDATE handling of unique secondary indexes when primary key changes

Currently, whenever we perform an UPDATE and the primary key changes, we delete the full row followed by an insert of the full row. I think this pattern can be optimized in how we handle the unique secondary indexes when the unique key doesn't contain NULL. In such a scenario, the key in the unique secondary index doesn't _necessarily_ change, so rather than performing a `Del` followed by a `CPut` we could skip the `Del` altogether. Furthermore, if we acquired the lock on this index during the initial scan, we could replace the `CPut` with a `Put` which would remove a locking `Get` under the buffered writes.

Jira issue: CRDB-48689