* 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.

* origin/master:
  Release version 1.7.0

* origin/master:
  Release version 1.7.0

- even for server initiated streams
- odd  for client initiated streams

This way I will be able to use Pkt.msg_id as real stream_id in go's Conn
because with even / odd scheme there is no possibility for id conflicts
in between two peers.

Reason: there are many failures that appear there also on pristine
master, v1.6.3, v.1.6 with both ZODB4 and ZODB3.

Simply disable to be able to see whether my changes do not introduce new errors.