Docs: rolling upgrade process seems incorrect

When reading the [rolling upgrade process](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades), you can see that we wrote:

* disable allocation
* upgrade node1
* upgrade node2
* upgrade node3
* ...
* enable allocation

That won't work as after a node has been removed and restarted, no shard will be allocated anymore.
So closing node2 and remaining nodes, won't help to serve index and search request anymore.

We should write:

* disable allocation
* upgrade node1
* enable allocation
* wait for shards being recovered on node1
* disable allocation
* upgrade node2
* enable allocation
* wait for shards being recovered on node2
* disable allocation
* upgrade node3
* enable allocation
* wait for shards being recovered on node3
* disable allocation
* ...
* enable allocation

I think this documentation update should go in 1.3, 1.4, 1.x and master branches.

Closes elastic#7973.

docs/reference/setup/upgrade.asciidoc

@@ -111,9 +111,7 @@ curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
 
 * Start the now upgraded node.  Confirm that it joins the cluster.
 
-* Repeat this process for all remaining nodes.
-
-* When the process is complete on all nodes, you can re-enable shard reallocation:
+* Re-enable shard reallocation:
 
 [source,sh]
 --------------------------------------------------
@@ -126,6 +124,9 @@ curl -XPOST 'http://localhost:9200/_cluster/nodes/_local/_shutdown'
 
 * Observe that all shards are properly allocated on all nodes.  Balancing may take some time.
 
+* Repeat this process for all remaining nodes.
+
+
 It may be possible to perform the upgrade by installing the new software while the service is running.  This would reduce downtime by ensuring the service was ready to run on the new version as soon as it is stopped on the node being upgraded.  This can be done by installing the new version in its own directory and using the symbolic link method outlined above.  It is important to test this procedure first to be sure that site-specific configuration data and production indices will not be overwritten during the upgrade process.
 
 [float]