Remove optimization on blk free operation

[Besroy]

The optimization in blk free may cause the following issue, just remove it and wait for GC handling:

• T1: blob1 is written with LSN 1 — [blkid=10, chunk=1, cnt=5].
• T2: blob1 is deleted with LSN 10, causing the last_append_offset to revert to 10.
• T3: blob2 is written with LSN 11 — [blkid=10, chunk=1, cnt=5].
• T4: The SM is terminated and restarted.
• T5: LSN 1 is replayed, committing block [blkid=10, chunk=1, cnt=5].
• T6: LSN 11 is replayed, committing block [blkid=10, chunk=1, cnt=5].
• T7: LSN 10 is committed, freeing block [blkid=10, chunk=1, cnt=5].
• T8: LSN 11 is committed again, but since the blocks have already been freed, they are not available for LSN 11.

[codecov-commenter]

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

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.10%. Comparing base (1a0cef8) to head (ab44065).
Report is 135 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #645      +/-   ##
==========================================
+ Coverage   56.51%   66.10%   +9.58%     
==========================================
  Files         108      109       +1     
  Lines       10300    10989     +689     
  Branches     1402     1505     +103     
==========================================
+ Hits         5821     7264    +1443     
+ Misses       3894     3012     -882     
- Partials      585      713     +128     

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

[JacksonYao287]

LGTM, let gc reclaim the space.

[xiaoxichen]

LGTM, @yamingk pls take a look.

It is very unlikely we delete/free on the tail so I am fine to leave it to GC.

[yamingk]

@xiaoxichen , can we pull out @hkadayam 's PR (maybe you guys have already done it?) to make sure the original purpose of this change is not broken and if is broken, it is expected with GC?
I remember this change in free is critical to avoid corruption during crash restart.

[Besroy]

@xiaoxichen , can we pull out @hkadayam 's PR (maybe you guys have already done it?) to make sure the original purpose of this change is not broken and if is broken, it is expected with GC? I remember this change in free is critical to avoid corruption during crash restart.

@yamingk I think the purpose not broken. PR #403 addresses the crash recovery process by introducing reserve_on_cache and reserve_on_disk. The former only happens during recovery, while the latter introduces the concept of m_commit_offset. The intent to rewind m_last_append_offset for the last block is just an optimiaztion for special case (free at the tail), which has been in place for some time. It seems that PR #403 just optimizes that part of the code . FYI please see this comment.