Add some logging about refused ADD_SUBNET
(it causes subsequent client disconnect so it's
important to know which subnet was at fault).
Maybe we should just ignore it completely.
Similar changes as was in 2327d3f6eb
but for del_subnet_h().
Before, we vere returning false (and causing disconnect of the
client) in case of tunnelserver and the client sending DEL_SUBNET
for non-his subnet or for subnet which owner isn't in our connection
list.
After the mentioned change to add_subnet_h() that routine does not
add such indirect owners to the connection list anymore, so that
was ok (owner == NULL and we return true).
But if we too has a connection with the node about which the client
is sending DEL_SUBNET notification, say, because that client lost
connection with that other node, we'll disconnect this client from
us too, returning false for indirect DEL_SUBNET.
Fix that by allowing and ignoring indirect DEL_SUBNET in tunnelserver
mode.
Also rearranged the function a bit, to match add_subnet_h() (in
particular, syntax-check everything first, see if we've seen this
request before).
And also fix some comments.
In TunnelServer mode, tinc server disconnects any client if it announces
indirect subnets -- subnets that are not theirs (e.g. subnets for nodes
the CLIENT has connections now, even if those nodes are known to the server
too). Fix that by ignoring such (indirect) announces instead.
While we're at it, move check for such indirect subnet registration to
before allocating new node structure, as in TunnelServer mode we don't
really need to know that other node.
- Convert cp to cp(); so that automatic indenters work.
- Convert constructions like if(x == NULL) to if(!x).
- Move all assignments out of conditions.
