fix duplicating&learning(5/n): the plog will be gc before comfirmed

## Bug Report
XiaoMi/rdsn#845 is fixing the bug #765, and test show the plog will not be lost when replay in learning, but in latest two test, when start duplicating to be ready replay and send, the log report the `max_gced_decree > start_decree`:
```
F2021-06-16 14:47:25.525 (1623826045525670453 19943) replica.rep_long9.0405001600000040: replica_duplicator.cpp:176:verify_start_decree(): assertion expression: max_gced_decree < start_decree
D2021-06-16 14:47:25.525 (1623826045525692473 19854) replica.default5.0401000400000021: pegasus_mutation_duplicator.cpp:95:pegasus_mutation_duplicator(): [268.20@10.132.5.1:32801] initialize mutation duplicator for local cluster [id:2], remote cluster [id:1, addr:c4tst-dup1]
F2021-06-16 14:47:25.525 (1623826045525701911 19943) replica.rep_long9.0405001600000040: replica_duplicator.cpp:176:verify_start_decree(): the logs haven't yet duplicated were accidentally truncated [max_gced_decree: 2809371, start_decree: 1, confirmed_decree: 0, last_decree: 0]
```

I haven't found the cause

Start by reproducing the latest two tests described in the report, then inspect the assertion in replica_duplicator.cpp:176 and the initialization path in pegasus_mutation_duplicator.cpp:95. Trace why max_gced_decree exceeds start_decree during duplication and confirm that the plog is retained when replay begins; done means the assertion no longer occurs in this scenario.

Written by the indexing model from the issue text.