Add text around what brokers should do upon failures

Provide more guidance for what should happen when things go wrong
so we can ensure a more consistent semantics and interop.

This should only be reviewed after openservicebrokerapi#353

Signed-off-by: Doug Davis <dug@us.ibm.com>

spec.md

@@ -818,8 +818,10 @@ $ curl http://username:password@service-broker-url/v2/service_instances/:instanc
 | 422 Unprocessable Entity | MUST be returned if the Service Broker only supports asynchronous provisioning for the requested plan and the request did not include `?accepts_incomplete=true`. The expected response body is: `{ "error": "AsyncRequired", "description": "This service plan requires client support for asynchronous service operations." }`, as described below (see [Service Broker Errors](#service-broker-errors). |
 
 Responses with any other status code will be interpreted as a failure and a
-deprovision request SHOULD be sent to the Service Broker to prevent an orphan
-being created on the Service Broker.
+deprovision request MUST be sent to the Service Broker to prevent an orphan
+being created on the Service Broker. However, while the platform will attempt
+to send a deprovision request, Service Brokers SHOULD automatically delete
+any resources associated with the failed provisioning request on their own.
 Service Brokers can include a user-facing message in the `description` field;
 for details see [Service Broker Errors](#service-broker-errors).
 
@@ -957,7 +959,11 @@ $ curl http://username:password@service-broker-url/v2/service_instances/:instanc
 | 400 Bad Request | MUST be returned if the request is malformed or missing mandatory data. |
 | 422 Unprocessable entity | MUST be returned if the requested change is not supported or if the request cannot currently be fulfilled due to the state of the service instance (e.g. service instance utilization is over the quota of the requested plan). Service Brokers SHOULD include a user-facing message in the body; for details see [Service Broker Errors](#service-broker-errors). Additionally, a `422 Unprocessable Entity` can also be returned if the Service Broker only supports asynchronous update for the requested plan and the request did not include `?accepts_incomplete=true`; in this case the expected response body is: `{ "error": "AsyncRequired", "description": "This service plan requires client support for asynchronous service operations." }` (see [Service Broker Errors](#service-broker-errors). |
 
-Responses with any other status code will be interpreted as a failure. Service brokers can include a user-facing message in the `description` field; for details see [Service Broker Errors](#service-broker-errors).
+Responses with any other status code will be interpreted as a failure and
+the Service Broker MUST NOT apply any of the requested changes to the
+service instance.
+Service brokers can include a user-facing message in the `description` field;
+for details see [Service Broker Errors](#service-broker-errors).
 
 #### Body
 
@@ -1159,10 +1165,12 @@ $ curl http://username:password@service-broker-url/v2/service_instances/:instanc
 | 422 Unprocessable Entity | MUST be returned if the Service Broker requires that `app_guid` be included in the request body. The expected response body is: `{ "error": "RequiresApp", "description": "This service supports generation of credentials through binding an application only." }` (see [Service Broker Errors](#service-broker-errors). |
 
 Responses with any other status code will be interpreted as a failure and an
-unbind request SHOULD be sent to the Service Broker to prevent an orphan being
-created on the Service Broker. Service brokers can include a user-facing
-message in the `description` field; for details see [Service Broker
-Errors](#service-broker-errors).
+unbind request MUST be sent to the Service Broker to prevent an orphan being
+created on the Service Broker. However, while the platform will attempt
+to send an unbind request, Service Brokers SHOULD automatically delete
+any resources associated with the failed bind request on their own.
+Service brokers can include a user-facing message in the `description` field;
+for details see [Service Broker Errors](#service-broker-errors).
 
 #### Body
 
@@ -1294,9 +1302,9 @@ $ curl 'http://username:password@service-broker-url/v2/service_instances/:instan
 | 410 Gone | MUST be returned if the binding does not exist. The expected response body is `{}`. |
 
 Responses with any other status code will be interpreted as a failure and the
-binding will remain in the marketplace database. Service brokers can include a
-user-facing message in the `description` field; for details see [Service
-Broker Errors](#service-broker-errors).
+binding MUST remain in the marketplace database.
+Service brokers can include a user-facing message in the `description` field;
+for details see [Service Broker Errors](#service-broker-errors).
 
 #### Body
 
@@ -1368,9 +1376,9 @@ $ curl 'http://username:password@service-broker-url/v2/service_instances/:instan
 | 422 Unprocessable Entity | MUST be returned if the Service Broker only supports asynchronous deprovisioning for the requested plan and the request did not include `?accepts_incomplete=true`. The expected response body is: `{ "error": "AsyncRequired", "description": "This service plan requires client support for asynchronous service operations." }`, as described below (see [Service Broker Errors](#service-broker-errors). |
 
 Responses with any other status code will be interpreted as a failure and the
-service instance will remain in the marketplace database. Service brokers can
-include a user-facing message in the `description` field; for details see
-[Service Broker Errors](#service-broker-errors).
+service instance MUST remain in the marketplace database.
+Service brokers can include a user-facing message in the `description` field;
+for details see [Service Broker Errors](#service-broker-errors).
 
 #### Body