Unicast bundling breaks MERGE3 with TCP transport

Start with two sub-groups [A] and [B,C].

What's supposed to happen is that MERGE3 sends INFO messages around that get seen by everyone, and then since there's more than one view out there it can figure out that a merge is required.

What actually happens is that INFO messages from A are seen only by A, and INFO messages from B and C are seen only by B and C. So no-one sees that a merge is required.

I think that this is related to the code in TP.java that goes:

        if(dest instanceof PhysicalAddress) {
            // We can modify the message because it won't get retransmitted. The only time we have a physical address
            // as dest is when TCPPING sends the initial discovery requests to initial_hosts: this is below UNICAST,
            // so no retransmission
            msg.setDest(null);
        }

Contrary to that comment, MERGE3's INFO messages use a physical address as dest. So we execute this code. Then I think that what happens is that by the time the bundler gets to sending these INFO messages, it thinks they're broadcast message. If you have a TCP transport that means that they are sent only to those members that are already in your group - which misses the point altogether.