Even if the user should have left backup mode before truncating
upstream, this change should help fixing his mistake and minimizing
the risk of data corruption.

The previous behaviour was to crash with:

  RuntimeError: upstream DB truncated

This led to 2 issues:

1. As long as upstream last tid remains older, it is impossible to
   start the backup cluster if it's able to connect to upstream:
   then to avoid another upstream downtime, it is required to fake
   a connection failure, e.g. with temporary firewall rules or
   different --upstream-* parameters, which is not practical.
2. Worse, if there's again new commits upstream with last tid newer
   than on backup, the user may miss to also truncate the backup
   cluster (even more if it's setup to restart automatically).