Add note about cluster state diffs (elastic#39847)

Mentions cluster state diffs in CS publishing docs.

docs/reference/modules/discovery/bootstrapping.asciidoc

@@ -27,10 +27,6 @@ fully formed. It is therefore better to bootstrap using at least three
 master-eligible nodes, each with a `cluster.initial_master_nodes` setting
 containing all three nodes.
 
-NOTE: In alpha releases, all listed master-eligible nodes are required to be
-discovered before bootstrapping can take place. This requirement will be relaxed
-in production-ready releases.
-
 WARNING: You must set `cluster.initial_master_nodes` to the same list of nodes
 on each node on which it is set in order to be sure that only a single cluster
 forms during bootstrapping and therefore to avoid the risk of data loss.

docs/reference/modules/discovery/publishing.asciidoc

@@ -34,6 +34,15 @@ which defaults to `90s`. If a node has still not successfully applied the
 cluster state update within this time then it is considered to have failed and
 is removed from the cluster.
 
+Cluster state updates are typically published as diffs to the previous cluster
+state, which reduces the time and network bandwidth needed to publish a cluster
+state update. For example, when updating the mappings for only a subset of the
+indices in the cluster state, only the updates for those indices need to be
+published to the nodes in the cluster, as long as those nodes have the previous
+cluster state. If a node is missing the previous cluster state, for example
+when rejoining a cluster, the master will publish the full cluster state to
+that node so that it can receive future updates as diffs.
+
 NOTE: {es} is a peer to peer based system, in which nodes communicate with one
 another directly. The high-throughput APIs (index, delete, search) do not
 normally interact with the master node. The responsibility of the master node