feat: two explicit queues for session work

[SgtPooki]

Title

feat: two explicit queues for session work

Description

This PR originally aimed to fix the infinite loop we hit when we were only getting a single provider (this only occurring in test envs that i'm aware of, but certainly possible elsewhere). However, it's now been updated to refactor the provider finding and querying logic so that it's a little more obvious what is happening.

Notes & open questions

A few main things that change with this PR:

1. We are now explicitly kicking off the findProviders task when findProviders is done (idle event)
2. We are only querying providers when we get a provider event, or when an existing session is queried with a new cid (we will query any currently known and non-evicted providers).
   • The latter was existing code that was always ran, but is no longer needed for non-child-item-retrieve events since we query on provider events now
3. We use the same found < count logic to determine if we found enough providers, or throw an error
4. On findProvider job error (failure event), we set a flag indicating that we failed to find more providers.
   • if queryProviders job is running, we do not throw this error, because queryProviderQueue idle will handle when triggered.
5. on queryProvider idle
   • if we found the block: we don't start up any more work
   • if signal aborted, we reject the retrieve promise
   • if foundProviders errored, we reject the retrieve promise: new error that we're done querying providers and could not get the block
   • if findProviders queue is empty, we kick it off again (this case covers the child-item-t-retrieve event where findProvidersQueue idle would have already been emitted on root-CID query)

Change checklist

• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation if necessary (this includes comments as well)
• [x] I have added tests that prove my fix is effective or that my feature works