Rpc: Add getConfirmedSignaturesForAddress

[CriesofCarrots]

Problem

For the history that an API node maintains, it's not possible to fetch the list of transactions that affect a given address. Now that we index signatures by address, the next step would be to return those signatures

Summary of Changes

• Fix AddressSignatures blockstore column to handle multiple transactions per address-slot (also clean up some iterator indexes in tests so changes are on in one place in the future)
• Add blockstore apis to return signatures by address (forward-looking to returning full transactions by address)
• Add getConfirmedSignaturesforAddress rpc endpoint to expose signatures-by-address data

Fixes #9317

[codecov]

Codecov Report

Merging #9407 into master will decrease coverage by 0.0%.
The diff coverage is 83.4%.

@@           Coverage Diff            @@
##           master   #9407     +/-   ##
========================================
- Coverage    81.1%   81.1%   -0.1%     
========================================
  Files         276     276             
  Lines       62223   62351    +128     
========================================
+ Hits        50519   50622    +103     
- Misses      11704   11729     +25     

[mvines]

Needs a API doc update.

I'm not able to sanely parse the name getAddressConfirmedSignatures. WDYT about getConfirmedSignaturesForAddress?

Overall the implementation itself looks great to me though

[CriesofCarrots]

@mvines , ready for another look.
Currently, both start_slot and end_slot are required, although I did wonder about making it consistent with getConfirmedBlocks, which only requires start_slot. Do you have any opinions on that?

[mvines]

@mvines , ready for another look.
Currently, both start_slot and end_slot are required, although I did wonder about making it consistent with getConfirmedBlocks, which only requires start_slot. Do you have any opinions on that?

Only requiring start_slot seems fine, but then we'd want to return the range that was searched in the response so they know where to search next. Maybe we should return the range regardless.

[CriesofCarrots]

@mvines , ready for another look.
Only requiring start_slot seems fine, but then we'd want to return the range that was searched in the response so they know where to search next. Maybe we should return the range regardless.

The optional end_slot is more problematic with getConfirmedTransactionsForAddress, which I'm working on now. It needs an optional encoding parameter as well, and the jsonrpc crate doesn't handle multiple optional positional parameters very well.

So I'd like to leave end_slot as-is. In that case, I don't think we should return the range. Sound okay?

Pull request has been modified.