feat: deprecate current epoch in pinned snapshot

[wenym1]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Motivation is described in #18214.

As we are deprecating MVCC support on a single hummock version, barrier read with consistency will greatly increase the overall complexity. As barrier read is not with high priority, we may give up the consistency in barrier read. Implementation-wise, instead of using a consistent uncommitted epoch for queries in all tables, we will change to use u64::MAX as the epoch to query data from all tables, which means we will read the latest data in all tables. In this way, while deprecating MVCC support on a single hummock version, we can still preserve the functionality of barrier read for query with higher freshness.

After deprecating the consistent barrier read, we can further deprecate the current epoch in pinned snapshot, and then we can deprecate the usage of HummockReadEpoch::Current(epoch), and the validate_read_epoch and seal_epoch of StateStore trait can be further deprecated.

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added test labels as necessary. See details.
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

Previously, when the session variable visibility_mode is set to all, while we are able to query uncommitted data, we still ensure consistency between the tables involved in the query. After this PR, when visibility_mode is set to all, we will change to query the latest uncommitted data, and there is no consistency between the involved tables, even if a read only transaction is begun.

[hzxa21]

Generally LGTM.

@zwang28 @xxhZs PTAL as well.

[chenzl25]

LGTM

[BugenZhao]

Why do we need this? 👀

[wenym1]

After this PR, we won't provide consistency support for barrier read, and the CI with visibility_mode set to all will fail in this PR.

[BugenZhao]

Do you mean that read-only transaction does not guarantee any isolation when visibility_mode is all? If so, shall we ban user from doing this to avoid confusion?

[wenym1]

For simplicity, I change to send a notice to user when the user explicitly start read only transaction with visibility_mode is set to all.

[yezizp2012]

🥵 After this PR, the e2e e2e_test/batch/transaction/read_only_multi_conn.slt and e2e_test/batch/transaction/now.slt will become flaky when testing it use ci-3cn-3fe-in-memory:

e2e_test/batch/transaction/read_only_multi_conn.slt          .. [FAILED]

failed to run `e2e_test/batch/transaction/read_only_multi_conn.slt`

Caused by:
    query result mismatch:
    [SQL] select count(*) from t;
    [Diff] (-expected|+actual)
    -   2
    +   1
    at e2e_test/batch/transaction/read_only_multi_conn.slt:19

e2e_test/batch/transaction/now.slt                           .. [FAILED]
--
  |  
  | failed to run `e2e_test/batch/transaction/now.slt`
  |  
  | Caused by:
  | query result mismatch:
  | [SQL] select * from v
  | except
  | select * from mv;
  | [Diff] (-expected\|+actual)
  | +   2024-08-29 06:29:20.948
  | +   2024-08-29 06:29:20.848
  | +   2024-08-29 06:29:20.748
  | +   2024-08-29 06:29:20.898
  | +   2024-08-29 06:29:20.698
  | +   2024-08-29 06:29:20.798
  | at e2e_test/batch/transaction/now.slt:30