kademlia: use IsSameAs instead of Match for capability index comparison

[acud]

Fixes a bug where full node gets added to the light node capability index because it satisfies the comparison in the capabilities Match function (because light nodes will always be fulfilling a subset of full node capabilities).
Instead, IsSameAs should be used when doing the comparison

[nolash]

Should there be a test that catches the case?

[acud]

Should there be a test that catches the case?

added.

also, please note - the tests in capability packages are full of copy paste errors. please review the changes that i've made to comments (some of them feel a bit incomprehensible) and tests. also, as a sidenote, it is very easy to get lost in capability names called "42:001" and "42:101"; why not go with names that signify the actual capabilities?

[janos]

Test TestCapabilityNeighbourhoodDepth is failing.

[nolash]

@acud So I am wondering now whether this is actually correct. The "light" and "full" client presets really are just temporary presets until we have proper capabilities negotiations logic in place.

Won't this change actually prohibit "light" nodes from connecting to full clients? In terms of capabilities "light" node preset is supposed to be a subset of "full" node preset. Instead of this, probably there should be some logic that prevents the full node from connecting to a light node, but not the other way around.

Sorry for not commenting this earlier, but my head has been elsewhere the last couple of weeks.

[acud]

@nolash can you please refer me to the code sanctioning a light client from connecting to a full node?

I'm not sure if I am aware of such. It might at some point prevent a full node from connecting to a light client (although I think that the kademlia SuggestPeer code uses the default index which aggregates all nodes).

Looking at:

swarm/network/kademlia.go

Lines 173 to 180 in 0bc6bef

	if vCap.Match(idxItem.Capability) {
	log.Trace("Added peer to capability index", "conn", ok, "s", s, "v", vCap, "p", p)
	if ok {
	k.capabilityIndex[s].conns, _, _ = pot.Add(idxItem.conns, newEntryFromPeer(ePeer), Pof)
	} else {
	k.capabilityIndex[s].addrs, _, _ = pot.Add(idxItem.addrs, newEntryFromBzzAddress(eAddr), Pof)
	}
	}

addToCapabilityIndex does not return an error, so I'm not really sure where sanctioning takes place.