[BugFix] fix lock release issue in cloud native pk table (backport #53878)

[mergify]

Why I'm doing:

When prepare_primary_index, PK index load will fail and remove this index from cache:

StatusOr<IndexEntry*> UpdateManager::prepare_primary_index(
        const TabletMetadataPtr& metadata, MetaFileBuilder* builder, int64_t base_version, int64_t new_version,
        std::unique_ptr<std::lock_guard<std::shared_timed_mutex>>& guard) {
    ......
    // Fetch lock guard before `lake_load`
    guard = index.fetch_guard(); <---- get lock guard
    Status st = index.lake_load(_tablet_mgr, metadata, base_version, builder);
    ...
    if (!st.ok()) {
        .....
        _index_cache.remove(index_entry); <---- remove index
        ....
        return Status::InternalError(msg);
    }

But PrimaryKeyTxnLogApplier still hold the lock guard. After PrimaryKeyTxnLogApplier been destroyed, lock guard will release the lock which address is invalid because PK index already been remove.

This will cause invalid address access, it lead to unexpected behavior like stucking at here:

What I'm doing:

If PK index load fail, we need to release the lock before PK index been removed.

This pull request includes changes to improve error handling in the UpdateManager class and adds a new test case to cover index load failures. The most important changes include releasing the lock guard before removing the index entry when load or prepare operations fail, and adding a new test case in LakePrimaryKeyPublishTest.

Improvements to error handling:

• be/src/storage/lake/update_manager.cpp: Added code to release the lock guard before removing the index entry if the load operation fails in prepare_primary_index.
• be/src/storage/lake/update_manager.cpp: Added code to release the lock guard before removing the index entry if the prepare operation fails in prepare_primary_index.

New test case:

• be/test/storage/lake/primary_key_publish_test.cpp: Added a new test case test_index_load_failure to LakePrimaryKeyPublishTest to verify the behavior when index load fails.

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

[mergify]

Cherry-pick of 35043dc has failed:

On branch mergify/bp/branch-3.1/pr-53878
Your branch is up to date with 'origin/branch-3.1'.

You are currently cherry-picking commit 35043dc0ad.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   be/src/storage/lake/update_manager.cpp

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   be/test/storage/lake/primary_key_publish_test.cpp

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr