ClientAPI.find_nodes behavior when messages get lost

## What was wrong?

inspired by: https://github.com/ethereum/ddht/pull/122/files/a1238887112f663e6c46696e3f0937bb3bd3df7a#r509003163

The current logic for a FINDNODES message is that the response may be spread across multiple messages. If any of these messages fail to be delivered our implementation will drop all of the responses and treat it as a timeout.

## How can it be fixed?

An alternate approach would be to return whatever messages we receive, even if all messages are not received since they will contain a subset of the the requested ENR records.

Care should be taken to ensure that there aren't undefined behaviors or security concerns in this approach.

Start at ClientAPI.find_nodes and trace how FINDNODES responses are collected and handled when one or more messages are lost. Read the referenced ethereum/ddht pull request for context, then verify the desired behavior and security implications; done means safely returning received ENR records without treating partial delivery as a timeout.

Written by the indexing model from the issue text.