DRY up batched KVStore reads utility methods

[tnull]

DRY up batched KVStore reads with `read_all_objects` helper

The parallel `JoinSet`-based batching loop was duplicated across
`read_payments` and `read_pending_payments`. Extract it into a generic
`read_all_objects<T: Readable>` helper that callers invoke directly
with the relevant namespace constants. Per-type log messages are
preserved via `std::any::type_name::<T>()`.

Co-Authored-By: HAL 9000

[ldk-reviews-bot]

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[ldk-reviews-bot]

🔔 1st Reminder

Hey @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[ldk-reviews-bot]

🔔 2nd Reminder

Hey @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[Camillarhi]

LGTM

[Camillarhi]

This now needs a rebase, there's a merge conflict.

[ldk-reviews-bot]

🔔 3rd Reminder

Hey @joostjager! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

[joostjager]

I am not sure a generic client-side read throttle is the right abstraction here.

I think the motivation is mainly VSS-specific? For local stores such as SQLite, this mostly limits task fan-out rather than real backend concurrency. Perhaps it should be implemented only in the VSS client. And perhaps longer term, a multi-key read would be helpful in the VSS protocol?

[tnull]

I am not sure a generic client-side read throttle is the right abstraction here.

Hmm, I tend to agree, though pre-existing.

I think the motivation is mainly VSS-specific?

Well, yes, presumably postgres could also benefit from it, though the store probably should switch to connection pooling anyways?

For local stores such as SQLite, this mostly limits task fan-out rather than real backend concurrency. Perhaps it should be implemented only in the VSS client. And perhaps longer term, a multi-key read would be helpful in the VSS protocol?

Yeah, maybe for now I should just switch to wrap VssStore in BatchingStore in this PR? WDYT?

[joostjager]

Yeah, maybe for now I should just switch to wrap VssStore in BatchingStore in this PR? WDYT?

I think this is a good move, and later expand either towards protocol-level multi reads for vss, or perhaps generalize for other backends if the need arises.

[tnull]

Discussed offline, decided we're not going with the BatchingStore abstraction right now, but only DRY up the read_ utility methods in io/utils.rs in this PR.

[joostjager]

Looks good, uncontentious. Rebase needed.

[tnull]

Looks good, uncontentious. Rebase needed.

Rebased, sorry, forgot about that before.