detect findUniqueOrThrow small fixes

[miguelff]

These are a set of fixes from your PR at prisma#4014, which was already really good.

I will answer your questions in prisma#4014 (comment) here too:

1. When mapping the findMany back to the findUniqueOrThrow payloads, we need to insert an error response, but I was having a hard time figuring out how to generate the correct error here (lots of wrapping and indirection in the various error types/enums).
   * I didn't try to hard to verify this, but it looks like findUnique with rejectOnUnauthorized would just return null, and create the error in the client, I assume that for findUniqueOrThrow the error message is intended to come from the engine instead of the client?

As long as the user_facing_error part is correct, given we are not treating the error internally before returning, it's OK, the client will make use of that portion of the error, so I simplified the error expression in the handler code

2. In CompactDocument we need to track if the original queries were using findUnique or findUniqueOrThrow for 2 reasons: we need to have the single field name to map back to, and we need to know if we should insert an error or just a null result when a result is missing

• I am currently assuming that findUniqueOrThrow and findUnique are batched separately. The batch ids generated, I think will be different between these 2 methods, so batching these together would also require client changes
• tracking this per query rather than per batch would add more complexity, and not sure if this would be worth the added complexity

For the moment, the proposed level of optimization looks good, let's leave it this way and not try to batch different kind of operations for the moment.

• This is currently tracked as a suffix string. This feels a bit hacky, but I have not written a ton of rust, and am not familiar enough with this code base to know the best way to track that state

I changed that to, instead to use a heap allocated string, use a QueryOptions bitflag byte, which was also used in other parts of the crate.

3. The regression test for the issue you mentioned explicitly check that things shouldn't be batched. I think it should be safe to update the test to allow batching, as long as the response doesn't change (it currently does because the errors are not being generated correctly), but want to confirm my understanding of the issue was correct before changing that

I think that's an OK assumption.

Please let me know how the proposed changes below look into your proposed patch, and if you decide to merge them, we can follow-up with them.

[hayes]

Thanks! This all makes sense to me, will merge it now