* origin/master:
  storage: start replicating the partition which is furthest behind
  master: fix possibly wrong knowledge of cells' backup_tid when resuming backup
  Minor comment/doc changes

This fixes the following case when the backup is far behing the upstream DB,
and there are transactions being committed at the same time:

1. replicate partition 0
2. replicate partition 0
3. replicate partition 1
4. replicate partition 0
5. replicate partition 1
6. replicate partition 2
7. replicate partition 0
...
and so on in a quadratic way.

When the upstream activity was too high, the backup could even be stuck looping
on the first partitions.

The issue happens when there were commits while the backup cluster was down.
In this case, the master thinks that these commits are already replicated,
reporting wrong backup_tid to neoctl. It solved by itself once:
- there are new commits triggering replication for all partitions;
- all storage nodes have really replicated.

This also resulted in an inconsistent database when leaving backup mode during
this period.