Replace operations should be atomic/robust in the face of runtime errors about pulumi

[pgavlin]

What concrete problem does this end up causing?

The design for this is that if the resource is deleted but has not yet been recreated, then it will be recreated by the next update (assuming it still exists). Once it has been deleted it should no longer be in the state file, so the state transition should be from no resource to a new resource.

[lunaris]

In some sense this is a subset of --continue-on-error (which we may decide is enough for this use case). Namely:

• You are performing an update which involves A (delete-before-replace) and B (does not matter)
• A's delete completes
• B throws an error
• The program terminates due to B's error before A's create/replace happens (which would succeed)
• You have downtime because A was deleted but not replaced

Here, you could either use --continue-on-error (ignore all errors), or argue that we make delete-before-replaces (or perhaps all chains not involved in an error) atomic/complete before the error terminates the program. Hope that makes sense (again, it might be that we don't pursue this and advise use of --continue-on-error, though in my mind there are distinct use cases).