Clarify the state of an instance after a failed update or delete

[fmui]

Update and delete operations may fail for many different reasons. For example:

• A deletion may fail because other instances or resources depend on the instance.
• Resources to do the update are not available at this time.
• A legal hold does not allow an instance to be altered or deleted.

In many cases, when such an operation fails, the service instance is untouched and still usable. From an application point of view nothing changed. (In the legal hold case there MUST be no change.)

For the update operation, the spec contains this sentence:

When the response includes a 4xx status code, the Service Broker MUST NOT apply any of the requested changes to the Service Instance.

That implies the service instance is still usable.

For the delete operation, we have this sentence:

...MUST be interpreted as a failure and the Platform MUST remember the Service Instance.

The word "remember” does not specify whether the instance is still operational or in an unusable state.
We should clarify what that means and maybe add another status code (409?) that let the broker tell the platform that the instance is untouched.

[fmui]

See PR #570.

[fmui]

See also issue #358.

[nilebox]

It would also be nice to have similar feature for "create" (provisioning) operation.
Otherwise platform has to always perform orphan mitigation "just in case" after failed async provisioning, even if nothing has been created.