[#29527] YSQL: Evict server hashmap cache entry on parse error received during connection reset

Summary:
A fix to remove the stale entry from server's hashmap in case of an error been received in connection manager has been implemented in [[ 1acabde | 1acabde ]]. Postgres returns a special packet `YBParsePrepareErrorResponse` consumed by conn mgr containing prepared statement needs to be removed from server hashmap.
**BUT** the new packet been returned was not been intercepted during the reset phase of the connection manager, when server object is not synchronised. Therefore it was getting ignored and no entry was been removed from server hashmap. This diff fixes the same above.

Test Plan:
Jenkins: all tests

**Hacky Manual Testing With Connection Manager**

Steps:
- Added the sleep in PARSE phase in postgres backend for a particular prepared statement name-Q. Make sure it's less than `ysql_conn_mgr_wait_timeout_ms`. So conn mgr wait for enough time.
- Add a failure of a parse for that particular prepared statement name (Q) in postgres backend after sleep.
- Started application, when parse gets stuck, kill the JDBC connection forcefully.
      Cmd to find port of JDBC connection: sudo ss -tn state established '( sport = :5433 or dport = :5433 )'
      Cmd to kill the connection sudo ss -K dst 10.150.3.175 dport = <port got from above cmd>.
- Client will get disconnected and server in connection manager will require to get synchronised. And hence we see YBParsePrepareErrorResponse packet in reset phase.
- Re-ran the same application and check in connection manager logs, we should never get "prepared statement <> does not exist" error for same prepared statement Q.

Reviewers: skumar, arpit.saxena, vikram.damle, asrinivasan

Reviewed By: skumar, arpit.saxena

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D48624

Author: Manav Kumar

src/odyssey/sources/backend.c

@@ -1106,6 +1106,11 @@ int od_backend_ready_wait(od_server_t *server, char *context, int count,
 					 machine_msg_size(msg));
 			machine_msg_free(msg);
 			continue;
+		} else if (type == YB_BE_PARSE_PREPARE_ERROR_RESPONSE) {
+			od_backend_evict_server_hashmap(server, context,
+				machine_msg_data(msg), machine_msg_size(msg));
+			machine_msg_free(msg);
+			continue;
 		} else if (type == KIWI_BE_READY_FOR_QUERY) {
 			od_backend_ready(server, machine_msg_data(msg),
 					 machine_msg_size(msg));