swift-ring-builder set_info should update replication ip/port even when not explicitly provided

[Tim Burke]

I'm in the midst of rebuilding a Swift cluster. The old "cluster" was really just a box with a bunch of drives in it; when the CPU died, I figured I'd take the opportunity to actually spread devices around a bit. The old ring looked like

$ swift-ring-builder object.builder
object.builder, build version 46, id f7be51f1798341c4be229d753e0ec763
256 partitions, 3.000000 replicas, 1 regions, 1 zones, 5 devices, 1.43 balance, 0.00 dispersion
The minimum number of hours before a partition can be reassigned is 0 (0:00:00 remaining)
The overload factor is 0.00% (0.000000)
Ring file object.ring.gz is up-to-date
Devices: id region zone ip address:port replication ip:port name weight partitions balance flags meta
            0 1 1 192.168.50.30:6203 192.168.50.30:6203 d1 8000.00 161 -0.42
            1 1 1 192.168.50.30:6204 192.168.50.30:6204 d2 8000.00 162 0.20
            3 1 1 192.168.50.30:6206 192.168.50.30:6206 d5 8000.00 161 -0.42
            4 1 1 192.168.50.30:6207 192.168.50.30:6207 d6 8000.00 161 -0.42
            5 1 1 192.168.50.30:6208 192.168.50.30:6208 d8 6000.00 123 1.43

I went to move (some of) the drives to their new homes:

$ swift-ring-builder object.builder set_info /d2 192.168.50.19:6203/d2 /d6 192.168.50.19:6204/d6 /d8 192.168.50.21:6203/d8 /d1 192.168.50.21:6204/d1
Device d1r1z1-192.168.50.30:6204R192.168.50.30:6204/d2_"" is now d1r1z1-192.168.50.19:6203R192.168.50.30:6204/d2_""
Device d4r1z1-192.168.50.30:6207R192.168.50.30:6207/d6_"" is now d4r1z1-192.168.50.19:6204R192.168.50.30:6207/d6_""
Device d5r1z1-192.168.50.30:6208R192.168.50.30:6208/d8_"" is now d5r1z1-192.168.50.21:6203R192.168.50.30:6208/d8_""
Device d0r1z1-192.168.50.30:6203R192.168.50.30:6203/d1_"" is now d0r1z1-192.168.50.21:6204R192.168.50.30:6203/d1_""

None of the replication IPs moved, which is some cruddy UX. If the old IP/port matches the old replication IP/port, and the new IP/port changes without specifying a replication IP/port, it seems like a pretty safe assumption that replication IP/port should move too.