Fix diff logic for server-side apply mode

[lblackstone]

Proposed changes

Related issues (optional)

Fix #1667

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[mikhailshilkov]

I think I understand the mechanics of the change but I'm missing the bigger picture. Could you give an example of why this is needed and how the merge fixes #1667? Any danger for regression in other diff scenarios that you can identify?

[viveklak]

Looks good. As an aside, we need to put some thought into making the provider a bit more independently testable. I don't think the integration testing framework allows validating diffs for instance.

[lblackstone]

I think I understand the mechanics of the change but I'm missing the bigger picture. Could you give an example of why this is needed and how the merge fixes #1667? Any danger for regression in other diff scenarios that you can identify?

#1667 (comment) has some more details. The server-side diff computes a different patch than the client-side diff, which led to a bug in our replacement computation. By merging those patches (preferring the server-side changes), both of the changes are considered.

The default diff behavior (client-side diff) will not change, and I can't think of a reason why this would break the opt-in server-side diff either.

[lblackstone]

As an aside, we need to put some thought into making the provider a bit more independently testable. I don't think the integration testing framework allows validating diffs for instance.

I agree. It seems like the diff computations are an area that could from some standardization across our native providers.