refresh_schema doesn't fast-forward binary log position

[acarapetis]

Describe the bug
I'll prefix this with the disclaimer that this may very well not be a bug, but might just be an oversight on my part on either how chameleon is meant to be used, or on how log-based replication works.

I recently had a replica stop running (not pg_chameleon's fault) for a few weeks, long enough that the source database cleared some binary logs that the replica had not yet processed. Recovering from this seems quite difficult - obviously just re-enabling and re-starting the replica won't work, so we have to copy all the data again. I figured that a chameleon refresh_schema would be enough to recover, but apparently after running this command the replica schema still points to the old location in the binary logs.

To Reproduce

1. Set up a pg_chameleon replication
2. Stop the replica
3. Make some changes in the source database
4. PURGE BINARY LOGS on the source database
5. Restart the replica. At this point, the replica fails with the error "Could not find first log file name in binary log index file", which is expected.
6. chameleon refresh_schema, which copies the entire contents of every table.
7. Re-enable and restart the replica. It fails again with the same error as before, with the replica schema pointing to the same binary log point as before.

Expected behavior
Since the full contents of the source schema are copied over, I would expect to only need the logs from that point forward to maintain the replica.

Environment(please complete the following information):

• OS: Centos 7
• MariaDB 10.2.12 on RDS
• PostgreSQL 11 on RDS
• Python 3.6.8