Docs: provide a concrete discussion and example for RLS race conditions.

Commit 43cd468cf0 added some wording to create_policy.sgml purporting
to warn users against a race condition of the sort that had been noted some
time ago by Peter Geoghegan.  However, that warning was far too vague to be
useful (or at least, I completely failed to grasp what it was on about).
Since the problem case occurs with a security design pattern that lots of
people are likely to try to use, we need to be as clear as possible about
it.  Provide a concrete example in the main-line docs in place of the
original warning.

doc/src/sgml/ref/create_policy.sgml

@@ -414,16 +414,8 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable
   </para>
 
   <para>
-   When reducing the set of rows which users have access to, through
-   modifications to row-level security policies or security-barrier views,
-   be aware that users with a currently open transaction may be able to see
-   updates to rows that they are theoretically no longer allowed access to,
-   as the new policies may not be absorbed into existing query plans
-   immediately.  Therefore, the best practice to avoid any possible leak of
-   information when altering conditions that determine the visibility of
-   specific rows is to ensure that affected users do not have any open
-   transactions, perhaps by ensuring they have no concurrent sessions
-   running.
+   Additional discussion and practical examples can be found
+   in <xref linkend="ddl-rowsecurity">.
   </para>
 
  </refsect1>