runtime: Remove status redefinitions from operations

These states are already defined in the "State" section.  There's no
need to redefine them in the operation sections.

Operation-level redefinitions are dicy anyway, because they imply
something testable about the immediately-after-this-operation time,
and it's not possible to run race-free tests of that time (e.g. the
process could die for other reasons between the successful 'create'
call and the 'state' call you made to look for a 'created' status).

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

runtime.md

@@ -93,8 +93,6 @@ Using the data in [`config.json`](config.md), this operation MUST create a new c
 This means that all of the resources associated with the container MUST be created, however, the user-specified program MUST NOT be run at this time.
 If the runtime cannot create the container as specified in [`config.json`](config.md), it MUST generate an error and a new container MUST NOT be created.
 
-Upon successful completion of this operation the `status` property of this container MUST be `created`.
-
 The runtime MAY validate `config.json` against this spec, either generically or with respect to the local system capabilities, before creating the container ([step 2](#lifecycle)).
 Runtime callers who are interested in pre-create validation can run [bundle-validation tools](implementations.md#testing--tools) before invoking the create operation.
 
@@ -108,17 +106,13 @@ Attempting to start a container that does not exist MUST generate an error.
 Attempting to start an already started container MUST have no effect on the container and MUST generate an error.
 This operation MUST run the user-specified program as specified by [`process`](config.md#process).
 
-Upon successful completion of this operation the `status` property of this container MUST be `running`.
-
 ### Kill
 `kill <container-id> <signal>`
 
 This operation MUST generate an error if it is not provided the container ID.
 Attempting to send a signal to a container that is not running MUST have no effect on the container and MUST generate an error.
 This operation MUST send the specified signal to the process in the container.
 
-When the process in the container is stopped, irrespective of it being as a result of a `kill` operation or any other reason, the `status` property of this container MUST be `stopped`.
-
 ### Delete
 `delete <container-id>`