RPC-call getSignaturesForAddress misbehaves if before/until args land on one of multiple transactions within a slot.

[RGafiyatullin]

Problem

Strange behaviour when before and/or until refer a transaction that is not the only transaction within the slot

Summary of Changes

An attempt to streamline the selection of transaction, so that the first/last/other slots are treated less differently.

Also this PR yields the entries exactly in the newest-to-oldest order as returned by the address_signatures_cf, without putting it into temporary collections, reversing them etc.

Disclaimer: this is a draft PR. The primary goal is to trigger the CI and with some luck — a conversation.

[CriesofCarrots]

The issue you link to is known, with multiple pre-existing github issues (see, for example, the links in #33419). That issue is fixed in v1.18.
If you have other motivation for a refactor, feel free to make that argument.

[RGafiyatullin]

That issue is fixed in v1.18.

Great!

If you have other motivation for a refactor, feel free to make that argument.

I personally find the proposed code a bit more readable, but that is inherently subjective, I can't possibly insist.

The reasons I see it this way are:

• single call to the column-iterator, that is massaged into the required sequence of signatures in a self-explanatory manner;
• reduce the level of nesting in the code that forms the exclusion-filter hash-sets;
• find_address_signatures_for_slot a single use function, that requires reversing the list of entries, that it returns.

[RGafiyatullin]

I admit that some more work has to be done:

• doing the ensure_lowest_cleanup_slot gymnastics;
• removing the unused timers.

But there are chances for an early return out of this PR, so I'm prepared to address the above if it would make sence.

[willhickey]

This repository is no longer in use. Please re-open this pull request in the agave repo: https://github.com/anza-xyz/agave