Clarify rolling-upgrade docs (#47279)

Note to upgrade the master-eligible nodes last, and note that
`cluster.initial_master_nodes` should not be set.

docs/reference/upgrade/rolling_upgrade.asciidoc

@@ -7,6 +7,12 @@ a time so upgrading does not interrupt service. Running multiple versions of
 not supported, as shards cannot be replicated from upgraded nodes to nodes
 running the older version.
 
+It is best to upgrade the master-ineligible nodes in your cluster first and then
+upgrade the master-eligible nodes. Once enough of the master-eligible nodes have
+been upgraded they may form a cluster that nodes of older versions cannot join.
+If you upgrade the master-eligible nodes last then all the other nodes will not
+be running an older version and so they will be able to join the cluster.
+
 Rolling upgrades are supported:
 
 * Between minor versions
@@ -53,6 +59,11 @@ include::shut-down-node.asciidoc[]
 --
 include::upgrade-node.asciidoc[]
 include::set-paths-tip.asciidoc[]
+
+[[rolling-upgrades-bootstrapping]]
+NOTE: You should leave `cluster.initial_master_nodes` unset while performing a
+rolling upgrade. Each upgraded node is joining an existing cluster so there is
+no need for <<modules-discovery-bootstrap-cluster,cluster bootstrapping>>.
 --
 
 . *Upgrade any plugins.*