Locators in HELLO message are assumed to belong to the same ZID

[oteffahi]

Describe the bug

The orchestrator assumes that the locators contained in a HELLO message are endpoints that lead to the same Zenoh instance (i.e same ZID). This assumption is invalid, and a manually crafted HELLO message containing locators for different Zenoh instances causes the following:

• For peers and routers: the decision to attempt to connect to a scouted locator depends on the configuration of scouting/multicast/autoconnect and scouting/multicast/autoconnect_strategy (and respectively their gossip config counterparts). These configurations are applied depending on the HELLO message's mode, which does not necessarily match the mode of the instances behind each locator. Crafted HELLO messages can therefore lead to opening transports and links that do not respect the scouting configuration.
• For clients: if configured with multilink (transport/unicast/max_links >= 2), trusting the contents of HELLO messages and assuming that all the locators within it belong to the same Zenoh instance (i.e same ZID) causes the client to connect to different peers, and therefore have more than one transport open at a time, which invalidates many assumptions made in its routing layer and contradicts the design of Zenoh clients.

To reproduce

Tested by changing the orchestrator's code, hardcoding two different endpoints in the HELLO message sent in response to a Scout message.

• Cause a client to open multiple transports: Note that for this to work on a client with multilink, both locators in the HELLO message must have a parameter (ex: tcp/127.0.0.1:7447?rel=1 and tcp/127.0.0.1:7448?rel=0). 1- Start the router with the custom code and with multicast scouting enabled, listening on one of the two endpoints contained in the crafted HELLO message. 2- Start a non-modified router, with scouting disabled, and listening on the other locator. 3- Start a non-modified client with multicast scouting enabled and transport/unicast/max_links set to 2. The client will establish a transport with both routers.
• Cause a router to connect to a peer despite its scouting/multicast/autoconnect config: 1- Start the router with the custom code and with multicast scouting enabled, listening on one of the two endpoints contained in the crafted HELLO message. 2- Start a non-modified peer, with scouting disabled, and listening on the other locator. 3- Start a non-modified router with multicast scouting enabled, no listener endpoint, and scouting/multicast/autoconnect: ["router"]. The router will connect to the peer despite its autoconnect config stating otherwise.

System info

• MacOS 15.5
• Apple Silicon M2
• Zenoh release 1.5.1