Doc: update VACUUM FREEZE query conflict guidance.

Commit 1de58df4, which added page-level freezing, taught VACUUM to reuse
each page's "set-visibility-map" snapshotConflictHorizon for freezing
(at least in the vast majority of cases where freezing went ahead).
This made VACUUM FREEZE much less prone to generating recovery conflicts
on standbys; VACUUM FREEZE became only slightly more likely to cause
recovery conflicts than an equivalent VACUUM.

Update old documentation that specifically warned of the likelihood of
recovery conflicts from VACUUM FREEZE.  Explain the same general issue
(the issue of VACUUM generating recovery conflicts even in the absence
of dead row cleanup) using the example of conflicts caused by VISIBLE
WAL records.

doc/src/sgml/high-availability.sgml

@@ -1873,10 +1873,16 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
    </para>
 
    <para>
-    Experienced users should note that both row version cleanup and row version
-    freezing will potentially conflict with standby queries. Running a manual
-    <command>VACUUM FREEZE</command> is likely to cause conflicts even on tables with
-    no updated or deleted rows.
+    Row version cleanup isn't the only potential cause of conflicts with
+    standby queries.  All index-only scans (including those that run on
+    standbys) must use an <acronym>MVCC</acronym> snapshot that
+    <quote>agrees</quote> with the visibility map.  Conflicts are therefore
+    required whenever <command>VACUUM</command> <link
+     linkend="vacuum-for-visibility-map">sets a page as all-visible in the
+     visibility map</link> containing one or more rows
+    <emphasis>not</emphasis> visible to all standby queries.  So even running
+    <command>VACUUM</command> against a table with no updated or deleted rows
+    requiring cleanup might lead to conflicts.
    </para>
 
    <para>