Faster sync by collecting esplora ureq thread handles

[nickfarrow]

Description

Speeds up esplora ureq syncing. Taken from #560

The current sync just creates a map of scripts to joinhandles which doesn't yet spawn the sync threads due to lazy evaluation. In the following handles.map(), the thread handles are sequentially evaluated and joined. With the fix, the handles are collected so that the threads spawn in parallel, and then joined

Notes to the reviewers

I had to add a #[allow(clippy::needless_collect)] so that it wouldn't complain about collecting and then iterating. (Perhaps clippy is partially responsible for this issue!)

Tested sync performance by doing a fresh sync on an existing gun wallet.

---- Before fix ---
real	0m13.121s
real	0m13.367s
real	0m13.211s

---- After fix ----
real	0m5.516s
real	0m5.251s
real	0m5.594s

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[notmandatory]

Now that you're fixing the parallel execution should we worry about running out of some resource if a wallet has lots of scripts and transactions to sync? seems like this could swamp a low power esplora server or at least exceed some point of diminishing returns for spawning new threads. You don't need to address it in this PR but but do you have any thoughts for how to address this issue? maybe some sort of thread pool?

[LLFourn]

Now that you're fixing the parallel execution should we worry about running out of some resource if a wallet has lots of scripts and transactions to sync? seems like this could swamp a low power esplora server or at least exceed some point of diminishing returns for spawning new threads. You don't need to address it in this PR but but do you have any thoughts for how to address this issue? maybe some sort of thread pool?

Note that the number of requests is limited. It does them in batches according to concurrency.

[notmandatory]

ACK adef166