Upon receiving ACK/reply directly, only update next-hop if we’re the *sole* relayer

[GUVWAF]

Fixes #7839.

Simulated the same scenario with the interactive simulator and it works correctly now.
Previously it indeed set the next-hop while it shouldn’t:

INFO  | 19:44:23 12 [Router] Received traceroute from=0x12, id=0x21ceb01c, portnum=70, payloadlen=28
INFO  | 19:44:23 12 [Router] Route traced:
0x10 --> 0x11 (-7.00dB) --> 0x12 (-7.25dB)
(-12.00dB) 0x10 <-- 0x12
INFO  | 19:44:23 47 [Router] Update next hop of 0x12 to 0x12 based on ACK/reply

After this:

INFO  | 18:43:19 56 [Router] Route traced:
0x10 --> 0x11 (-8.25dB) --> 0x12 (-8.75dB)
(-10.00dB) 0x10 <-- 0x12
INFO  | 18:43:19 56 [Router] ACK/reply for 0x12, wasRelayOrigPacket=0, wasSoleRelay=0

wasSoleRelay=0 means it wasn’t the sole relayer (because 0x11 forwarded it), and the next-hop does not get set.

[mihvoi]

Sounds good. I am looking forward to see it merged and released. My C is a little rusty (pun not intended) to review the code.

For a future implementation, I would expect it to set 0x11 as nextHop for 0x12 based on forward traceroute.
For short term, it is better to not set a wrong nextHop at all.