uTP requires ENR or Node from discv5 on Incoming connection request

[kdeme]

This is perhaps rather a nim-eth issue as the code lives there. However, it is related to Portal / Fluffy only.

@KonradStaniec pointed out that when currently a talkresp message gets lost, there is an issue here because the node gets replaced from the routing table on lack of valid response.

One suggestion was to re-add the Node on failure, in the utp discv5 code. However, a re-add is not certain to happen as the replacement cache might have already filled the routing table.

In fact, the issue can perfectly occur even without the a lost talkresp message. A node, which is not in the routing table, might initiate a uTP connection. We wouldn't be able to get Node or Record. Of course, in this process, the node must have completed a handshake and thus a session exists. However, the Record or Node is nowhere stored aside from potentially in the routing table. There has not been a use case for this in the existing discv5 use cases.

The whole requirement of the Node object stems from the fact that the talkReq proc (and others) require the Node as parameter. This in its turn is required for the scenario where no session exists and handshake needs to be done, which requires the pubkey of the Node (aside from NodeId and Address).

Some potential solutions:

• Have some ENR storage / cache that holds at least all the ENRs for which currently a session exists.
• Have some hacky version of talkReq proc, which only sends a regular message packet (no store of node for potential handshake). It would then only require the NodeId + Address combination as parameters. It also doesn't need to wait or care about the response. This would probably work because the Portal messages before would have set up the session. But it is obviously quite the hack, but then again, the use of talkreq/talkresp for uTP in Portal is a hack itself. One could also still use the original talkreq for the first message.