perf: remove redundant read on upsert

[Weakky]

Overview

fixes prisma/prisma#5686

When performing an upsert (that's not native), a redundant select was always performed. This PR mitigates that issue.

SQL diff

Before

SELECT `User`.`id` FROM `User` WHERE `User`.`email` = ?;
SELECT `User`.`id` FROM `User` WHERE `User`.`email` = ?;
UPDATE `prisma`.`User` SET `firstName` = ? WHERE `prisma`.`User`.`id` IN (?) AND `prisma`.`User`.`email` = ?;
SELECT `User`.`id` FROM `User` WHERE `User`.`id` = ?;

SELECT `User`.`id` FROM `User` WHERE `User`.`email` = ?;
UPDATE `prisma`.`User` SET `firstName` = ? WHERE `prisma`.`User`.`id` IN (?) AND `prisma`.`User`.`email` = ?;
SELECT `User`.`id` FROM `User` WHERE `User`.`id` = ?;

[codspeed-hq]

CodSpeed Performance Report

Merging #4248 will not alter performance

_{Comparing perf/upsert-redundant-select (f948b91) with main (79f2257)}

Summary

✅ 11 untouched benchmarks

[miguelff]

Neat!

[janpio]

Would be nice if we had a test covering these queries, right?

[miguelff]

We have tests for non-native upserts, I don't think testing the generated queries should be necessary, tho.

[michael-land]

@Weakky just curious, Why not use the RETURN statement to avoid an additional SELECT?
from

SELECT `User`.`id` FROM `User` WHERE `User`.`email` = ?;
UPDATE `prisma`.`User` SET `firstName` = ? WHERE `prisma`.`User`.`id` IN (?) AND `prisma`.`User`.`email` = ?;
SELECT `User`.`id` FROM `User` WHERE `User`.`id` = ?;

to

SELECT `User`.`id` FROM `User` WHERE `User`.`email` = ?;
UPDATE `prisma`.`User` SET `firstName` = ? WHERE `prisma`.`User`.`id` IN (?) AND `prisma`.`User`.`email` = ? RETURNING `User`.`id`

In v5.1, the UPDATE already utilizes the RETURN statement."

---