Routing Loops

Nobody has claimed this yet.

So I'm not sure how we're actually populating our peer tables and whether that actually follows Kademlia routing specifications. Depending on how we do this, routing loops seem like they are a possibility in the current network protocol for nodes that are more than two hops apart. As an example, given the topology

```
A : { B, C }
B : { A, C }
C : { A, B, D }
D : { C, E }
E : { D }
```

and the xor-distance score to `E` (from `A`) being C > B > D > A > E.

Since we only send to the closest node, and exclude the peer that we received the message from, the route from `A` to `E` ends up looking like this: `A -> B -> C -> A` when it should be `A -> B -> C -> D -> E`

Are we certain that the network protocol will always converge? Should we track visited nodes as part of metadata that's sent with each directed message (`SubReq`, `TranscodeSub`, `TranscodeResponse`)?

One possibility is to bypass the problem altogether since we don't actually need DHT style routing overlays for broadcaster-transcoder interactions, with the requirement that transcoders are public (https://github.com/livepeer/go-livepeer-basicnet/issues/34).

Start by tracing how peer tables are populated and how SubReq, TranscodeSub, and TranscodeResponse are routed; compare that behavior with the Kademlia routing question raised here. Determine whether visited-node metadata or the public-transcoder approach from issue #34 is needed, and define done as a protocol decision that prevents the A-B-C-A loop.

Written by the indexing model from the issue text.