refactor(remote_timeline_client): Split deletion into unlinking + deletion

[koivunej]

Quest: #4745. Prerequisite for #4938. Original #4938 (comment).

The new Layer implementation has so far been using RemoteTimelineClient::schedule_layer_file_deletion from Layer::drop but it was noticed that this could mean that the L0s compaction wanted to remove could linger in the index part for longer time or be left there for longer time. Solution is to split the RemoteTimelineClient::schedule_layer_file_deletion into two parts:

• unlinking from index_part.json, to be called from end of compaction and gc
• scheduling of actual deletions, to be called from Layer::drop

The added methods are added unused.

[koivunej]

I did start to wonder how is that the compaction is sane without a single add+remove operation. Perhaps we have just been lucky enough? Timeline::compact for L0 => L1 compaction will always do:

1. upload layer(s)
2. remove layers <-- schedules index part upload after inmem changes but before deletions
3. (there's a later schedule_index_upload_for_file_changes, but now there is nothing pending)

So not lucky at all, the multiple method call interface is just essentially giving this batched operation. Between the steps and loop around step 1 above there could be other interactions, and that would be fine even with these changes.

[github-actions]

2340 tests run: 2224 passed, 0 failed, 116 skipped (full report)

---

Code coverage (full report)

• functions: 53.5% (8564 of 16012 functions)
• lines: 80.9% (49773 of 61507 lines)

---

_{The comment gets automatically updated with the latest test results
c292bc7 at 2023-10-24T15:46:30.517Z :recycle:}