stx_supply and stx account balance endpoint perf issues

[zone117x]

The query used for extended/v1/stx_supply is getting expensive and taking several seconds (or timing out) when not getting a cache-hit.

We now have an ft balance table which can calculate the total STX supply near-instantly, which we should switch to using.

EDIT:
Account stx balance endpoints are also starting to have perf issues due to this same underlying problem.

[zone117x]

Recently (Feb 26th), a series of stx balance lookups were slow and ended up causing reliability issues. Those read queries have been growing at something like a sublinear rate to the number of tx rows associated with a given address (or at least growing at a constant (O(1)) rate), which is starting to become a problem due to the volume of txs that can be associated with a given address. The current endpoints to determine STX balance performs a query that aggregates all stx debits and credits from every tx and stx-transfer row related to the account (e.g. tx fees, coinbase rewards, stx inbound and outbound transfers). For the stx_supply query, this debit+credit aggregation is performed on the entire tables.

We have a new-ish table that tracks balances for each address<->token, which means this endpoint could issue balances queries that only need to read a single row. It's the same table powers these fast endpoints: https://api.hiro.so/extended/v1/tokens/ft/stx/holders

We could make that change for non-STX tokens right now, but for STX balances there is a known bug where some address balances are slightly off. Perhaps its worth making the change anyway knowing some balances will be off, and then we'll get more information on any balance discrepancies, which could help us fix the issue.

I've bumped this issue priority to urgent.

[wileyj]

copypaste from #2226 since tracking was moved here:

This presents almost identically to #2147

In this case, querying a an API like:

http://localhost:3999/extended/v1/address/{principle}/balances

can take quite long (in some cases, i waited over 120s). the host resources/db resources were mostly unchanged and other requests were served during the wait, so it doesn't seem to be blocking.

~$ time curl -sL localhost:3999/extended/v1/address/{principle}/balances | jq -r
{
  "stx": {
    "balance": "14433751",
    "total_sent": "152295994",
    "total_received": "255265978",
    "total_fees_sent": "88536233",
    "total_miner_rewards_received": "0",
    "lock_tx_id": "",
    "locked": "0",
    "lock_height": 0
...
real	0m31.282s
user	0m0.039s
sys	0m0.006s

After the first query for the balance, subsequent requests return quickly (as expected), so it feels really similar #2147