Explore: Optimize removing from a to-many relationship

[bart-degreed]

For adding resources to a to-many relationship (example: POST /shop/1/relationships/articles), we don't fetch all existing articles first. This makes adding a few articles to an existing large set efficient.

But for removing resources from a to-many relationship (example: DELETE /shop/1/relationships/articles), we rely on EF Core to fetch the existing set of articles first. If that set is large, the operation becomes very inefficient.

This issue concerns exploring if we can do better. At the minimum, we'll need to fetch the set of resources-to-be-deleted (which is usually empty), so that we won't fail when a user is detaching something that wasn't attached (JSON:API requires that). We'll need to look for ways to trick the EF Core change tracker into believing the whole set was fetched.

If we don't find a way to optimize this, we should put some controls in place that prevent clients from taking down the service on such incoming requests. For example, we could choose to add a configurable threshold for the existing number of items in the set. If this setting is activated, we'll do a COUNT(*) on the set before trying the operation. If the count exceeds the threshold, we'll abort with an error message.