Add wallet / address group endpoints

[mononaut]

No re-index required.

This draft PR adds some new endpoints at /addresses/txs, /scripthashes/txs, /addresses/txs/summary, and /scripthashes/txs/summary, which act as multi-address versions of the corresponding single address/scripthash APIs.

The general idea is to allow paging through the combined history of multiple addresses while keeping the cost per request low and without needing to spam separate requests for each address.

This is mostly a placeholder implementation to support developing/testing mempool/mempool#4831, and probably wants to be heavily refactored and optimized before it's deployed anywhere.

(e.g. the ReverseScanGroupIterator custom multi-iterator should maybe be replaced by something from itertools, and it would be nice to avoid fetching every unconfirmed txid for every address in paginated /txs calls)

[junderw]

I would be curious to see a comparison between this and just hitting the other endpoints consecutively... maybe write a simple bash script to try out both against this PR.

I feel like it might be significantly slower, although when accounting for latency in actual prod environments the ability to combine them into a single request might make things a bit faster.

Just looking over the code real quick, it seems pretty sane... but yeah, some testing needs to be done imo.

[mononaut]

I think the main benefit of doing it this way is that you can share the pagination budget across several addresses.

e.g. currently you'd get rate limited or banned trying to fetch transaction history for 50 addresses with one transaction each in separate requests, even though the actual processing cost is similar to a single request for an address with many transactions.

[wiz]

does this require a re-index?

[junderw]

No re-index required

[wiz]

ok then please rebase

[junderw]

LGTM

A little bit worried about prod performance though.

Local testing seems ok, but it's hard to simulate tons of users wanting to "check their wallets" and a bunch of people hit this endpoint all at once.

[junderw]

Also @mononaut if there's another reason for this to still be a Draft let me know. I'll let you remove the Draft status once you get a chance.

[mononaut]

I'm planning to proceed with this, since it's the best way to support mempool/mempool#5562, and I think it's a generally useful feature regardless.

But I do want to address the performance concerns before taking back out of draft.

[mononaut]

it took a while to understand the new parallel iterator stuff, but it seems like a big improvement.

I'll take this out of draft now, since between that and the after_txid optimization I'm very happy with the performance now.

[junderw]

1. It feels like a little bit of repetition can be removed from the TxidLocation stuff.
2. We should probably include the after_txid/TxidLocation stuff into the single address / summary endpoints as well.

[junderw]

LGTM again.

[mononaut]

Tested ACK @ [b7d9b3a]