[API-382] Optimizations for volume leaders query

[schottra]

Noticed we were doing a full sequential scan of the table for every request due to how we were choosing to filter.
Some things that can help us be efficient:

• Since we are tracking only changes in AUDIO volume against pools we care about, first filter sol_token_account_balance_changes to only changes affecting those vaults, THEN do the joining to user token accounts and the remainder of the filtering.
• We have an index of (mint, block_timestamp) on the STABC table, and we only care about AUDIO vaults, so updated the filtering to leverage that index directly.
  • Note: original query was based on created_at, which would be when we indexed them, not block_timestamp which is more accurate (cc @rickyrombo to make sure this is safe to use).
• We don't need to filter the "user change" side of this by date, since we are joining those based on signature/change/mint.
• We can do the "address exclusion" part at the very end. It's much more efficient for us to filter the small record set we end up with than to mess up our index scan earlier on trying to check each account against a list.
• I moved the dbc/dammv2 pools into our excluded addresses table instead of adding special WHERE conditions on the initial changes query. Since we won't see migrations that often, it's fine to filter those out at the end instead of it being a condition we have to check all the time.