Allow UNLISTEN in hot-standby mode.

Since LISTEN is (still) disallowed, UNLISTEN must be a no-op in a
hot-standby session, and so there's no harm in allowing it.  This
change allows client code to not worry about whether it's connected
to a primary or standby server when performing session-state-reset
type activities.  (Note that DISCARD ALL, which includes UNLISTEN,
was already allowed, making it inconsistent to reject UNLISTEN.)

Per discussion, back-patch to all supported versions.

Shay Rojansky, reviewed by Mi Tar

Discussion: https://postgr.es/m/CADT4RqCf2gA_TJtPAjnGzkC3ZiexfBZiLmA-mV66e4UyuVv8bA@mail.gmail.com

doc/src/sgml/high-availability.sgml

@@ -1633,6 +1633,11 @@ if (!triggered)
        Plugins and extensions - <command>LOAD</>
       </para>
      </listitem>
+     <listitem>
+      <para>
+       <command>UNLISTEN</command>
+      </para>
+     </listitem>
     </itemizedlist>
    </para>
 
@@ -1722,7 +1727,7 @@ if (!triggered)
      </listitem>
      <listitem>
       <para>
-       <command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>
+       <command>LISTEN</>, <command>NOTIFY</>
       </para>
      </listitem>
     </itemizedlist>
@@ -1730,8 +1735,8 @@ if (!triggered)
 
    <para>
     In normal operation, <quote>read-only</> transactions are allowed to
-    use <command>LISTEN</>, <command>UNLISTEN</>, and
-    <command>NOTIFY</>, so Hot Standby sessions operate under slightly tighter
+    use <command>LISTEN</command> and <command>NOTIFY</command>,
+    so Hot Standby sessions operate under slightly tighter
     restrictions than ordinary read-only sessions.  It is possible that some
     of these restrictions might be loosened in a future release.
    </para>