update Peer.HasShortID as part of topology merge

[rade]

This was missing.

There are two parts to this change:

1. updating the Peers.byName mapping when HasShortID changed (in addition to the existing update on ShortID change). We need to be careful about the sequencing here - both ShortID and HasShortID must be set between the calls to deleteByShortID and addByShortID, since the former is meant to delete the existing entry (hence use the old values) and the latter add the new entry (hence use the new values).
2. update a peer when the received info has the same version and UID but the current record has HasShortID=false, and the received info has HasShortID=true. This caters for the case where we receive an update about a weave 1.2+ peer first via a pre-1.2 peer (which does not transmit ShortIDs, and always sets HasShortID=false) and subsequently via a 1.2+ peer. The former update will force us to communicate with that peer over the 'sleeve' overlay. We want to accept the latter update, even though the version is the same, in order to update the ShortID and HasShortID, so we can switch to fastdp.

Fixes #1731.

[rade]

I haven't done any testing of this. We do have coverage of the new/changed code, but presumably only because we've added to conjunctions which are satisfied by earlier clauses.

[rade]

I haven't done any testing of this.

Have done some now...

1. built the current 1.3 head and deployed that to my vagrant VMs
2. downloaded weave 1.1.2 onto my desktop. NB: do not build this; it won't work when compiled with go1.5

Then...

host1$ weave launch
host2$ weave launch
deskt$ weave launch $HOST1 $HOST2
deskt$ weave status connections
-> 192.168.48.12:6783    established ee:53:20:87:88:d2(host2)
-> 192.168.48.11:6783    established ae:d6:8c:ad:be:df(host1)
host1$ weave status connections
<- 192.168.48.1:45937    established sleeve ca:a3:0f:5b:eb:b5(xps)
<- 192.168.48.12:38852   established sleeve ee:53:20:87:88:d2(host2)
host2$ weave status connections
-> 192.168.48.11:6783    established sleeve ae:d6:8c:ad:be:df(host1)
<- 192.168.48.1:53376    established sleeve ca:a3:0f:5b:eb:b5(xps)

So host1 and host2 discover each other via deskt, but only establish a sleeve overlay connection.

Now with this branch...

deskt$ weave status connections
-> 192.168.48.11:6783    established 32:fa:db:63:78:97(host1)
-> 192.168.48.12:6783    established e6:fc:ae:d4:c3:11(host2)
host1$ weave status connections
<- 192.168.48.1:56893    established sleeve 56:a9:e4:95:db:2f(xps)
<- 192.168.48.12:38864   established fastdp e6:fc:ae:d4:c3:11(host2)
host2$ weave status connections
<- 192.168.48.1:48767    established sleeve 56:a9:e4:95:db:2f(xps)
-> 192.168.48.11:6783    established fastdp 32:fa:db:63:78:97(host1)

where host1 and host2 managed to establish a fastdp overlay connection.

So this test confirms the 1st problem and fix identified in #1731. I cannot think of an easy way of testing the 2nd.