Summary:
Currently, when the user sets `yb_read_time` GUC variable in a pg session to read the data as of an older time in the past a.k.a. time-traveling queries, we don't disallow write DML statements (INSERT, UPDATE, DELETE, SELECT FOR UPDATE/SHARE). Users might mistakenly try to write data in such a session which might either throw a serialization error or write data successfully with current time stamps, making the semantics unclear to the user. Allowing writes in such a session might lead to correctness issues. For example, If the write is a fast path write, we skip conflict resolution on regular DB (and only do conflict resolution on intentsDB). This is incorrect behavior since the read time is influenced by yb_read_time.

This diff disallows any non read-only DML statements when the user sets the `yb_read_time` to a non-zero value to simplify the semantics of time-traveling queries.
This means disallowing:
- Write DMLs (INSEERT, UPDATE, DELETE).
- SELECT FOR UPDATE/SHARE etc..
- Running time traveling queries in serializable isolation level. However, we allow read-only serializable transactions.

All the queries are disallowed in serializable isolation level as even the read-only queries are not pure reads (they need to acquire read locks).

If the user wants to read older data and write it again. Ex: "I want to get my deleted rows back scenario", the user can export the output of the time-traveling query into csv and then insert the csv back in a normal pg session.
Jira: DB-15131

Test Plan: ./yb_build.sh --cxx-test pgwrapper_pg_read_time-test --gtest_filter PgMiniTestBase.DisallowWriteDMLsWithYbReadTime

Reviewers: pjain, hsunder, patnaik.balivada

Reviewed By: patnaik.balivada

Subscribers: ybase, yql, slingam

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