fix: noop one2m nested connect

[Weakky]

Overview

fixes prisma/prisma#17103

When performing a noop update on MySQL & MongoDB, the returned count of "affected rows" by the updateMany mutation was 0. This was breaking nested connect mutations which ensures the mutation has happened by relying on this count.

prisma-engines/query-engine/core/src/query_graph_builder/write/nested/connect_nested.rs

Lines 234 to 240 in a99c688

	if let QueryResult::Count(c) = query_result {
	if c != &expected_id_count {
	return Err(QueryGraphBuilderError::RecordNotFound(format!(
	"Expected {expected_id_count} records to be connected after connect operation on one-to-many relation '{relation_name}', found {c}.",
	)));
	}
	}

This PR does the following:

• Updates mysql_async (fix: pass CLIENT_FOUND_ROWS mysql_async#1) so that it passes the CLIENT_FOUND_ROWS flag. This changes the behavior of the affected count returned for mutations (UPDATE/INSERT etc). It makes MySQL return the FOUND rows instead of the AFFECTED rows.
• Updates the updateMany connector logic on MongoDB to rely on the matched_count instead of the modified_count
• Adds a regression test

Note that relying on the "matched count" (found rows) instead of the "modified count" (affected rows) does not break OCC because it still would return 0 if the filter doesn't match any row (because the "discriminant" field (eg: version field) got updated by another update).

It does change what updateMany and deleteMany now returns for MySQL. We believe the only "meaningful" count that can be used in an application to do any kind of logic is 0 though. Since 0 will still be returned in useful cases, we don't believe this is a breaking change.

[tomhoule]

very neat!