[BACKPORT 2024.2.2][#26297] YSQL: Fix xid handling in REFRESH MV [NONCONCURRENTLY] during major version upgrade

Summary:
D42159 handling the generation of PostgreSQL XIDs for `REFRESH MATERIALIZED VIEW CONCURRENTLY`.
It did not handle scenarios where a nonconcurrent refresh silently uses temp tables.
D41504 introduced one such scenario: when a major version upgrade is in progress,
a `REFRESH MATERIALIZED VIEW [NONCONCURRENTLY]` uses temporary tables to handle
new data to be inserted into the materialized view.

This revision handles the above scenario by treating it the same as a concurrent refresh with respect to
clearing the XID on transaction commit.
Jira: DB-15640

Original commit: dbeec7c / D42332

Test Plan:
Run the following test:
```
./yb_build.sh --cxx-test integration-tests_ysql_major_upgrade_matview-test --gtest_filter YsqlMajorUpgradeMatviewTest
```

Jenkins: urgent

Reviewers: fizaa, hsunder

Reviewed By: fizaa

Subscribers: smishra, yql

Tags: #jenkins-ready

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

Author: karthik-ramanathan-3006

src/postgres/src/backend/commands/matview.c

@@ -315,9 +315,14 @@ ExecRefreshMatView(RefreshMatViewStmt *stmt, const char *queryString,
 	/*
 	 * Required to allow the creation for the temp table since we directly
 	 * call make_new_heap instead of going through DefineRelation.
+	 * For postgres xid cleanup, mark the current transaction as running a
+	 * concurrent refresh.
 	 */
 	if (yb_in_place_refresh)
+	{
 		YBCForceAllowCatalogModifications(true);
+		YbSetTxnWithPgOps(YB_TXN_USES_REFRESH_MAT_VIEW_CONCURRENTLY);
+	}
 
 	/*
 	 * Create the transient table that will receive the regenerated data. Lock