[BugFix] fix MetdataCache concurrency issue

[luohaha]

Why I'm doing:

In previous PR, we introduced MetadataCache to achieve LRU strategy for rowset metadata memory manage, and when rowset been evict, then we will call this function:

void MetadataCache::_cache_value_deleter(const CacheKey& /*key*/, void* value) {
    reinterpret_cast<Rowset*>(value)->close();
}

to close rowset and release metadata memory.

But in some case, this rowset which pointer point to could has been destroy, but _cache_value_deleter doesn't know that and will still keep calling close(), and it will lead to concurrency issue.

What I'm doing:

This pull request includes several changes to the MetadataCache class and related functionality in the rowset module. The main goals are to improve memory management by using std::weak_ptr for cached rowsets and to rename the warmup_rowset method to refresh_rowset for clarity. Additionally, a new concurrency test is added to ensure thread safety.

Memory management improvements:

• be/src/storage/rowset/metadata_cache.cpp: Changed MetadataCache::cache_rowset to use std::weak_ptr<Rowset> for better memory management and updated the _insert method accordingly. [1] [2]
• be/src/storage/rowset/metadata_cache.cpp: Modified _cache_value_deleter to handle std::weak_ptr<Rowset> and ensure proper cleanup of cached rowsets.

Method renaming for clarity:

• be/src/storage/rowset/metadata_cache.cpp and be/src/storage/rowset/metadata_cache.h: Renamed warmup_rowset to refresh_rowset to better reflect its purpose. [1] [2] [3]
• be/src/storage/rowset/rowset.cpp: Updated calls to warmup_rowset to use the new refresh_rowset method.
• be/test/storage/rowset/metadata_cache_test.cpp: Updated test cases to use refresh_rowset instead of warmup_rowset. [1] [2]

New test for concurrency:

• be/test/storage/rowset/metadata_cache_test.cpp: Added a new test test_concurrency_issue to verify the thread safety of the MetadataCache when caching rowsets concurrently.

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

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.3
  • 3.2
  • 3.1
  • 3.0
  • 2.5

[github-actions]

[Java-Extensions Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[FE Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[BE Incremental Coverage Report]

✅ pass : 10 / 10 (100.00%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	be/src/storage/rowset/rowset.cpp	1	1	100.00%	[]
🔵	be/src/storage/rowset/metadata_cache.cpp	9	9	100.00%	[]