discv5 + encrypted channel : findnodes and topicquery response format

[FrankSzendzielarz]

The current spec proposes that for a 'streamed' response , such as Nodes, the approach should be to just break up the overall message into MTU-sized datagrams and in the header include a {MessageNumber of N} message counter.

The rationale is twofold: 1) the recipient should know how many to expect without having to wait for what would be quite a long timeout 2) to support future message ordering

In the current prototype code, this field is missing. I suggest adding it back so that in smaller networks or when certain buckets are underpopulated , or when querying for very close buckets (bucket 30 in a 32 bit id for example) , the recipient does not have to stall for seconds.

Also there is the scenario that because of UDP lossiness a datagram might be lost. If the sender tries to send multiple datagrams as a batch (eg: bucket nodes parts 1, 2, and 3) and part 2 is lost, the higher level protocol or the specific implementation might want to know if the full set was received , if the peer is reliable, and in future may even wish to re-request the lost message.

Similarly for TopicQuery responses.

[fjl]

See #85, it updates the spec and includes the total number of responses.

[fjl]

Closing because #85 is merged.