Improve replication since_seq parameter

[jiahuili430]

Overview

• If there is no checkpoint and no since_seq, then replicate from scratch.
• If there is no checkpoint but since_seq is defined, then replicate with
  the since_seq field.
• If both checkpoint and since_seq exist, use the checkpoint to replicate.
• If the request includes since_seq field, the replication ID will be changed.

Testing recommendations

Related Issues or Pull Requests

Related issue: #5867

Checklist

• This is my own work, I did not use AI, LLM's or similar technology
• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[nickva]

+1

[nickva]

Very neat idea so we can compare replication IDs!

[jiahuili430]

Thanks to your original code, it's very concise and easy to extend! I reused most of them.

[nickva]

Let's wait for @rnewson's review as well since this implements his idea

[rnewson]

very neatly done and a welcome improvement to since_seq behaviour.

I spun up a 3 node dev cluster and took this through some manual testing and observed the correct behavior.

Specifically;

1. I made a database and filled it with thousands of documents
2. I called _replicate with source/target and a since_seq of the current update seq of the db after step 1
3. I observed that the response correctly said "no_changes". and no checkpoint was made, as no work was done.
4. I then added ten more documents.
5. I called _replicate against with same args as step 2 and the response correctly said docs_read:10 and docs_written:10. the log confirmed it called _changes with my original since_seq
6. I did step 5 again and got a "no_changes" response and confirmed in the log that _changes was called with the update_seq from the checkpoint made at the end of step 5.