Issue Addressed

Lookups without peers should be allowed to exist for some time. See this common race condition:

1. Receive unknown block parent event
2. Create child lookup with zero peers
3. Parent is processed, before receiving any attestation for the child block
4. Child lookup is attempted to make progress but has no peers
5. We receive an attestion for child block and add a peer to the child block lookup

In step 4 we could drop the lookup because we attempt to issue a request with no peers available. This has two issues:

• We may drop the lookup while some other block component is processing, triggering an unknown lookup error. This can potentially cause unrelated child lookups to also be dropped when calling drop_lookup_and_children.
• We lose all progress of the lookup, and have to re-download its components that we may already have there cached.

Instead, there's no negative for keeping lookups with no peers around for some time. If we regularly prune them, it should not be a memory concern (TODO: maybe yes!).

This PR fixes the race condition seen in first issue of:

• Stuck lookup reports #5833

Proposed Changes

Do not immediately drop a lookup when attempting to do a download and it has no peers. Instead wait for all the following conditions before dropping it:

• Lookup has no peers
• Lookup is not awaiting any event (i.e. not processing a block component)
• Some time has elapsed since its creation