[release/9.0] Take into account store-generated values when ordering update commands

[AndriySvyryd]

Fixes #33023

Description

EF orders update commands in a way that avoids breaking store constraints, like unique indexes.
E.g. if there's a unique index on a Name column and there's currently a row with Jared and a row with Sam. The user wants to update the first row to Sam and the second row to Artak. EF needs perform the second update first.

This gets complicated when the index is over a column with a store-computed value since EF cannot predict the value it will have after an update. A workaround is to duplicate the store logic in the C# implementation. This client-side value would never be sent to the store but could be used to determine the update order. However, this workaround was broken because we also needed to avoid dependency cycles in the updates that would prevent establishing an order when a row with the same value is deleted and inserted. The way we handled this was by collapsing the delete and insert into an update and ignoring the store-generated values for ordering purposes.

This change to the ordering logic uses more fine-grained approach for determining whether a store-generated value could affect the ordering that works for both scenarios.

Customer impact

For models with a unique index over a computed column the update order can no longer be correctly determined and will throw an exception if it doesn't happen to be correct. The workaround is to send updates to the affected table one-by-one, but this would have a negative perf impact.

How found

Customer reported

Regression

Yes, from 6.0.x

Testing

Tests added.

Risk

Medium. While this code has good test coverage, due to its nature it's hard to predict all the ramifications of this change.

[SamMonoRT]

@AndriySvyryd - this is for main correct? Given risk assessment (Medium), I would suggest against 9.0 release without proper testing and high confidence.

[AndriySvyryd]

@AndriySvyryd - this is for main correct? Given risk assessment (Medium), I would suggest against 9.0 release without proper testing and high confidence.

It's intended for 9.0 if approved. I do think we have proper testing and I have high confidence it won't cause a regression. It just carries inherent higher risk due to code complexity, similar to most changes in the query pipeline.