Fix UT: address UAF in TestRaftLogStore lifecycle_test under ASan

[Besroy]

This change restore pending callback tracking in LogDev::on_flush_completion to fix the UT TestRaftLogStore.lifecycle_test UAF issue.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 40.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.29%. Comparing base (1a0cef8) to head (b5cbfd9).
⚠️ Report is 315 commits behind head on master.

Files with missing lines	Patch %	Lines
src/lib/logstore/log_dev.cpp	40.00%	1 Missing and 2 partials ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #860      +/-   ##
==========================================
- Coverage   56.51%   48.29%   -8.22%     
==========================================
  Files         108      110       +2     
  Lines       10300    12877    +2577     
  Branches     1402     6179    +4777     
==========================================
+ Hits         5821     6219     +398     
+ Misses       3894     2564    -1330     
- Partials      585     4094    +3509     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shosseinimotlagh]

m_pending_callback += req_map.size();
for(....){
}
m_pending_callback = 0;

[Besroy]

callback_lambda can be called in async-mode, if we directly set it as 0 out of callback_lambda, then the design of pending callback will not take effect -- the process remains pending_callback = n; -> pending_callback=0 -> all tasks complete, calling callback_lambda

[shosseinimotlagh]

there is a change here that m_pending_callback is zero but there exist still entities in the req_map

[shosseinimotlagh]

please change that both cases it resolves the issue

[Besroy]

Since it is non-atomic operation, it's unavoidable that m_pending_callback is zero but there exist still entities in the req_map. But your concern is valid. Although we call flush synchronously before m_id_logstore_map.clear() in stop(), and the on_flush_completion is called synchronously as well (meaning before clear, if the callback not complete, m_pending_callback must be > 0), we don't actually check m_pending_callback again after flush, so there's still a UAF risk.
I've update the pr to ensure logstore won't be cleared until all callbacks are called, please review again, thanks.