… rowsets #52995 (#52715)

Related: #52995

Problem Summary:

Make stale rowsets accessible across BEs to avoid E-230 (versions
already merged) in Read-Write Splitting senario.

… rowsets (apache#52995)

Related PR: apache#52440

In read-write splitting scenarios, some BE (Backend) nodes may have
already merged certain rowset versions, while another BE still attempts
to capture or access those rowsets.
When this happens, the BE reports error E-230 (versions already merged),
causing data access or synchronization to fail.

This PR introduces a remote rowset fetching mechanism, allowing a BE
that lacks the required rowset to fetch it from other BE nodes, instead
of failing with E-230.

- Added a remote fetch mechanism in the rowset management layer:
When a BE detects that a rowset is missing locally but has already been
merged, it will try to fetch the rowset from other BE nodes.
- Updated version and state checking logic to correctly identify the
“merged but missing” condition.
- Adjusted the rowset access path to trigger remote fetch rather than
throwing an immediate error.
- Added tests (unit/integration) to cover the new logic where
applicable.
- Ensured backward compatibility: If the BE already has the rowset
locally or read-write splitting is not enabled, the behavior remains
unchanged.

Introduce a remote rowset fetching mechanism to prevent E-230 (“versions
already merged”) errors in read-write splitting scenarios.
This improves BE fault tolerance when some nodes have merged versions
that others have not yet synchronized.

… rowsets (#52995) (#57271)

Related PR: #52995

In read-write splitting scenarios, some BE (Backend) nodes may have
already merged certain rowset versions, while another BE still attempts
to capture or access those rowsets.
When this happens, the BE reports error E-230 (versions already merged),
causing data access or synchronization to fail.

This PR introduces a remote rowset fetching mechanism, allowing a BE
that lacks the required rowset to fetch it from other BE nodes, instead
of failing with E-230.

- Added a remote fetch mechanism in the rowset management layer: When a
BE detects that a rowset is missing locally but has already been merged,
it will try to fetch the rowset from other BE nodes.
- Updated version and state checking logic to correctly identify the
“merged but missing” condition.
- Adjusted the rowset access path to trigger remote fetch rather than
throwing an immediate error.
- Added tests (unit/integration) to cover the new logic where
applicable.
- Ensured backward compatibility: If the BE already has the rowset
locally or read-write splitting is not enabled, the behavior remains
unchanged.

Introduce a remote rowset fetching mechanism to prevent E-230 (“versions
already merged”) errors in read-write splitting scenarios. This improves
BE fault tolerance when some nodes have merged versions that others have
not yet synchronized.

### What problem does this PR solve?

Issue Number: close #xxx

Related PR: #xxx

Problem Summary:

### Release note

None

### Check List (For Author)

- Test <!-- At least one of them must be included. -->
    - [x] Regression test
    - [ ] Unit Test
    - [ ] Manual test (add detailed scripts or steps below)
    - [ ] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
        - [ ] Previous test can cover this change.
        - [ ] No code files have been changed.
        - [ ] Other reason <!-- Add your reason?  -->

- Behavior changed:
    - [x] No.
    - [ ] Yes. <!-- Explain the behavior change -->

- Does this need documentation?
    - [ ] No.
- [x] Yes. <!-- Add document PR link here. eg:
apache/doris-website#1214 -->

### Check List (For Reviewer who merge this PR)

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->

… rowsets (apache#52995)

Related PR: apache#52440 

In read-write splitting scenarios, some BE (Backend) nodes may have
already merged certain rowset versions, while another BE still attempts
to capture or access those rowsets.
When this happens, the BE reports error E-230 (versions already merged),
causing data access or synchronization to fail.

This PR introduces a remote rowset fetching mechanism, allowing a BE
that lacks the required rowset to fetch it from other BE nodes, instead
of failing with E-230.

- Added a remote fetch mechanism in the rowset management layer:
When a BE detects that a rowset is missing locally but has already been
merged, it will try to fetch the rowset from other BE nodes.
- Updated version and state checking logic to correctly identify the
“merged but missing” condition.
- Adjusted the rowset access path to trigger remote fetch rather than
throwing an immediate error.
- Added tests (unit/integration) to cover the new logic where
applicable.
- Ensured backward compatibility: If the BE already has the rowset
locally or read-write splitting is not enabled, the behavior remains
unchanged.

### Release note

Introduce a remote rowset fetching mechanism to prevent E-230 (“versions
already merged”) errors in read-write splitting scenarios.
This improves BE fault tolerance when some nodes have merged versions
that others have not yet synchronized.