Stop generated cascade delete statements when the DeleteBehavior is database-side

[roji]

Currently, when setting DeleteBehavior.Cascade or SetNull, EF Core generates cascading statements for any tracked dependents. This isn't harmful, but is unnecessary since the behavior is already performed by the database.

[ajcvickers]

We should consider allowing this configuration at the same time as implementing cascades through set operations: #18960

[mmarinchenko]

+1 for this issue.

---

I think there should be a way to combine client-side and server-side behaviors.

Usually we have 3 options on the server side:

• Cascade - server deletes children
• SetNull - server updates children
• Restrict / NoAction - server checks the constraint and returns an error if necessary

We also have 2 options that try to mimic the typical server behavior on the client side:

• ClientCascade - client deletes loaded child entities
• ClientSetNull - client updates loaded child entities

And 1 option with a well-known name but a different meaning that does not mimic the behavior of the server:

• ClientNoAction - the client does nothing with children

1. There should be a ClientRestrict option for completeness - client checks whether any child entity is loaded and whether it is in a deleted / detached state, and throws an exception if necessary

2. Can ClientDetach be usable? For example if we want to do something with child entities after saving changes.

---

Then we can get the following:

• [Server]Cascade - server deletes children, client has default behavior
• ClientCascade - client changes the states of the loaded children and generates SQL for these changes, server has default behavior
• [Server]Cascade | ClientCascade - both server and client delete [loaded] children (this is current Cascade behavior)
• [Server]Cascade | ClientNoAction - server deletes children, client does nothing (good for performance but inconsistent on client side)
• [Server]Cascade | ClientDetach - server deletes children, client detaches loaded children from context (still better than current Cascade for performance and semi-consistent on client side)
• [Server]Cascade | ClientRestrict - server deletes children, but client checks whether any child entity is loaded and is not in the delete/detach state and throws an exception if necessary before saving changes (still better than current Cascade for performance and good for consistency)
• etc...

For me, this is much more flexible and convenient than current implementation.

[AndriySvyryd]

This depends on #34361 to avoid sending the commands in incorrect order.