Add clarity around conurrent updates

From the f2f:
Proposal: In the “Blocking Operations” section change it to say “...that mutate the same resource…” instead of “...that act on the same set of resources...”

&& creating Binding is not necessary considered mutating an Instance, it’s a Broker’s choice

&& move “Blocking Operations” out from under Async

&& change 422 in createBinding response status code table to include this concurrency stuff

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

spec.md

@@ -13,6 +13,7 @@
   - [Synchronous and Asynchronous Operations](#synchronous-and-asynchronous-operations)
     - [Synchronous Operations](#synchronous-operations)
     - [Asynchronous Operations](#asynchronous-operations)
+  - [Blocking Operations](#blocking-operations)
   - [Polling Last Operation](#polling-last-operation)
     - [Polling Interval and Duration](#polling-interval-and-duration)
   - [Provisioning](#provisioning)
@@ -352,22 +353,28 @@ If the query parameter described above is present, and the broker executes the r
 
 An asynchronous response triggers the platform marketplace to poll the endpoint `GET /v2/service_instances/:instance_id/last_operation` until the broker indicates that the requested operation has succeeded or failed. Brokers MAY include a status message with each response for the `last_operation` endpoint that provides visibility to end users as to the progress of the operation.
 
-#### Blocking Operations
+## Blocking Operations
 
-Brokers do not have to support concurrent requests that act on the same
-set of resources.  If a broker receives a request that it is not able to
+Brokers do not have to support concurrent requests that mutate the same
+resource.  If a broker receives a request that it is not able to
 process due to other activity being done on that resource then the broker
-MUST reject the request with an HTTP `422 Unprocessable Entity`.
-The HTTP body of the response MUST include a `description` property
-explaining the reason for the failure.
+MUST reject the request with an HTTP `409 Conflict` and
+the following body:
 
-Sample response:
 ```
 {
+  "error": "ConcurrencyError",
   "description": "Another operation for this service instance is in progress"
 }
 ```
 
+Note that per the [Orphans](#orphans) section, this error response does not
+cause orphan mitigation to be initiated. Therefore, platforms receiving
+this error response SHOULD resend the request at a later time.
+
+Brokers MAY choose to treat the creation of a binding as a mutation of
+the corresponding service instance - it is an implementation choice.
+
 ## Polling Last Operation
 
 When a broker returns status code `202 Accepted` for [Provision](#provisioning), [Update](#updating-a-service-instance), or [Deprovision](#deprovisioning), the platform will begin polling the `/v2/service_instances/:instance_id/last_operation` endpoint to obtain the state of the last requested operation. The broker response MUST contain the field `state` and MAY contain the field `description`.
@@ -782,7 +789,7 @@ $ curl http://username:password@broker-url/v2/service_instances/:instance_id/ser
 | 201 Created | MUST be returned if the binding was created as a result of this request. The expected response body is below. |
 | 400 Bad Request | MUST be returned if the request is malformed or missing mandatory data. |
 | 409 Conflict | MUST be returned if a service binding with the same id, for the same service instance, already exists but with different parameters. The expected response body is `{}`, though the description field MAY be used to return a user-facing error message, as described in [Broker Errors](#broker-errors). |
-| 422 Unprocessable Entity | MUST be returned if the 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." }`. |
+| 422 Unprocessable Entity | MUST be returned if the 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." }`. Additionally, if the broker rejects the request due to a concurrent request to create a binding for the same service instance, then this error MUST be returned (see [Blocking Operations](#blocking-operations)). |
 
 Responses with any other status code will be interpreted as a failure and an unbind request will be sent to the broker to prevent an orphan being created on the broker. Brokers can include a user-facing message in the `description` field; for details see [Broker Errors](#broker-errors).