[BugFix] fix race condition issue about persistent index's l0

[luohaha]

Why I'm doing:

In apply thread, persistent index will be modified and _l0 can be destroy and re-create. At the same time, another thread may visit _l0 by PersistentIndex::memory_usage.
There will be race condition issue here.

What I'm doing:

Add atomic val _memory_usage, calculate it each time when persistent index been modified, and PersistentIndex::memory_usage is only need to return _memory_usage, which is thread safe.

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

[trueeyu]

Add test case

[trueeyu]

        std::unique_lock wrlock(_lock);
        _l1_vec.emplace_back(std::move(l1_st).value());
        _l1_merged_num.emplace_back(1);
    }
    // clear l0
    _l0->clear();   please check this code

[trueeyu]

    new_l1_vec.emplace_back(std::move(l1_st).value());
    new_l1_merged_num.emplace_back((merge_l1_end_idx - merge_l1_start_idx) * merge_num);
    {
        std::unique_lock wrlock(_lock);
        _l1_vec.swap(new_l1_vec);
        _l1_merged_num.swap(new_l1_merged_num);
    }
    _l0->clear();  //here

[github-actions]

[FE Incremental Coverage Report]

✅ pass : 0 / 0 (0%)

[github-actions]

[BE Incremental Coverage Report]

✅ pass : 45 / 45 (100.00%)

file detail

	path	covered_line	new_line	coverage	not_covered_line_detail
🔵	be/src/storage/persistent_index.cpp	38	38	100.00%	[]
🔵	be/src/storage/primary_index.cpp	2	2	100.00%	[]
🔵	be/src/storage/persistent_index.h	1	1	100.00%	[]
🔵	be/src/storage/tablet_updates.cpp	4	4	100.00%	[]

[trueeyu]

Will 2.5/3.0 have the problem?

[github-actions]

@Mergifyio backport branch-3.0

[github-actions]

@Mergifyio backport branch-2.5

[mergify]

backport branch-3.3

✅ Backports have been created

• #43718 [BugFix] fix race condition issue about persistent index's l0 (backport #43569) has been created for branch branch-3.3

[mergify]

backport branch-3.2

✅ Backports have been created

• #43719 [BugFix] fix race condition issue about persistent index's l0 (backport #43569) has been created for branch branch-3.2 but encountered conflicts

[mergify]

backport branch-3.1

✅ Backports have been created

• #43720 [BugFix] fix race condition issue about persistent index's l0 (backport #43569) has been created for branch branch-3.1 but encountered conflicts

[mergify]

backport branch-3.0

✅ Backports have been created

• #43721 [BugFix] fix race condition issue about persistent index's l0 (backport #43569) has been created for branch branch-3.0 but encountered conflicts

[mergify]

backport branch-2.5

✅ Backports have been created

• #43722 [BugFix] fix race condition issue about persistent index's l0 (backport #43569) has been created for branch branch-2.5 but encountered conflicts