Fix error handling in getCopyDataMessage() and pqFunctionCall3()

Commit f6f0542266 changed getNotify(),
getParameterStatus(), and related libpq message-processing paths to
abandon the connection on out-of-memory errors.

However, getCopyDataMessage() and pqFunctionCall3() did not handle
this new fatal-error state. Both can process asynchronous
NotificationResponse and ParameterStatus messages while waiting for
other responses. If one of those messages triggered a fatal error, these
loops continued processing instead of reporting it immediately.

Fix this by checking for a saved fatal error after processing an
asynchronous message. If the connection has been abandoned, return the
appropriate error immediately instead of continuing to parse input.

Backpatch to v18, where commit f6f0542266 introduced this issue.

Author: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Reviewed-by: Ewan Young <kdbase.hack@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Discussion: https://postgr.es/m/CAO6_XqpGfm+XHE1OzS=_+jroeDOxhhGa11P3cbm9q2gT05yorA@mail.gmail.com
Backpatch-through: 18

src/interfaces/libpq/fe-protocol3.c

@@ -1931,6 +1931,13 @@ getCopyDataMessage(PGconn *conn)
 				return -1;
 		}
 
+		/*
+		 * An error may have been triggered while processing the message,
+		 * report it if it's the case
+		 */
+		if (conn->error_result && conn->status == CONNECTION_BAD)
+			return -2;
+
 		/* Drop the processed message and loop around for another */
 		pqParseDone(conn, conn->inCursor);
 	}
@@ -2425,6 +2432,13 @@ pqFunctionCall3(PGconn *conn, Oid fnid,
 				return pqPrepareAsyncResult(conn);
 		}
 
+		/*
+		 * An error may have been triggered while processing the message, bail
+		 * out
+		 */
+		if (conn->error_result && conn->status == CONNECTION_BAD)
+			return pqPrepareAsyncResult(conn);
+
 		/* Completed parsing this message, keep going */
 		pqParseDone(conn, conn->inStart + 5 + msgLength);
 		needInput = false;