Per-node failure tables

Per-node failure tables are an idea suggested a while ago, whose purpose is:
- To automatically route around cancer nodes which always fail a particular key.
- To allow repeated requests to find content which was in the wrong place on the network. (This may encourage unwanted behaviour i.e. infinitely many requests for a given key, but such behaviour will happen anyway).

Per-node failure tables are an evolution of FailureTables, an idea which was implemented in Freenet 0.5 to reduce load caused by polling clients, but was removed after it was discovered that it could cause some seriously bad behaviour, and could be exploited very easily.

The idea is simply that if we have recently sent a request for key K to a given node, and it has failed, then we should try the next-best node (according to routing), rather than sending it to the same node all over again for it to probably fail.

This deals with the first problem: If a node always DNFs a particular key, then we will try the other nodes, and will find it.

Two big remaining questions:
1. Should we have a flag, or a counter, for each node:key pair?
- If a flag, then after we have tried each of our nodes, it will go back to the closest one for all subsequent requests. This would discourage flooding in order to find rare keys, however it also would reduce the effectiveness of our protection against cancer nodes, if the best node according to routing is the cancer node. Protection against cancer nodes is the primary objective, so a flag is not suitable.
- Or should we have a counter? If we have a counter, then repeated requests will alternate between all our available nodes. This means that enough requests will eventually visit all nodes within a few hops, and the content will be found if it is just slightly off where it should be. Obviously if this happens, it should be propagated back to its proper routing location via being automatically reinserted. It also means that a cancer node will not degrade with time.

2. Should we ever block requests entirely, rather than misrouting them?
Classic FailureTables simply failed (fatally) a request if it had DNFed in the last X minutes. This reduced load from polling keys significantly, however frequent requests for the key would keep the failure tables blocking the key forever without any requests for it progressing; this is clearly bad! Should per-node failure tables attempt to address the polling load issue by sometimes just failing a request? I don't think so, PassiveRequests provide a better solution.