IOPS have been modelled as a resource since Nomad 0.1 but has never
actually been detected and there is no plan in the short term to add
detection. This is because IOPS is a bit simplistic of a unit to define
the performance requirements from the underlying storage system. In its
current state it adds unnecessary confusion and can be removed without
impacting any users. This PR leaves IOPS defined at the jobspec parsing
level and in the api/ resources since these are the two public uses of
the field. These should be considered deprecated and only exist to allow
users to stop using them during the Nomad 0.9.x release. In the future,
there should be no expectation that the field will exist.
Switch from global-redis-check for the example job's service name to
redis-cache. The former name is really confusing and someone finally
called us out on it:
https://groups.google.com/d/msg/nomad-tool/3RTh6CyYkWk/vEe_Sj7lAAAJ
Also specifically mention that the `service.name` parameter is what is
advertised in Consul.
The Superset method on Resources used to return a string in the format of “[resource name] exhausted”.
This was leading to the output in plan/create job API DimensionExhausted to return keys like
```
"DimensionExhausted": {"cpu exhausted": 1}
```
This was not anywhere documented, however, one of the examples on the website showed it like this.
The other side effect of this is that the CLI formats the strings from the name of the key leading to output like
```
* Dimension "cpu exhausted" exhausted on 1 nodes
```
The sample request incorrectly used `https://nomad.rocks/v1/job/my-job/deployments` which listed all deployments for the specified job. The sample request has therefore been updated to use the correct endpoint which returns only the jobs most recent deployment.
