fix: inscriptions settings btn and available balance

[alter-eggo]

Try out Leather build 3a1b17e — Extension build, Test report, Storybook, Chromatic

this pr fixes:

• available balance tooltip text
• disable swaps on testnet
• updates query package to prevent infinite brc20 request, related pr
• inscription settings btn styles:

[fbwoolf]

I initially approved this, but I'm not confident adding locked in the tooltip is correct without actually deducting it from the account card available balance?

[fbwoolf]

Bitflow isn't initializing for me on this branch, but it might be a local issue. Looking into it...

EDIT: Nvm, this was me and my .env file.

[markmhendrickson]

🚧 Undergoing QA

I'll test the following cases manually. Can we also add automated tests for them, even if warranted in separate PR(s) to unblock release of this one?

Ideally we'd have automated tests that check on the UI level in addition to the function one, to ensure that updated values appear immediately once their related events occur (i.e. to ensure that caching doesn't incur delays to updating their display as expected by users).

-> Update: These cases are now captured by this issue: https://github.com/leather-io/issues/issues/425

[kyranjamie]

This feature, and all the bugs/inaccuracies it introduced are the result of fast-paced work building on top an already old/poorly-implemented feature.

We need to rethink how we manage UTXOs, and in turn calculate balances, from ground up. This was already in-flight prior to the sBTC rush. It may well be better to focus on that than first fixing these issues?

I think @alexp3y and I should return to this next week, focusing on:

1. Finalising UTXO fetching worker, exposed via UtxoService, and implementing this in extension
2. Implementing and testing a BalanceService that aggregates data from necessary sources (Address UTXOs, Pending Mempool UTXOs etc) to derive accurate balances

[fbwoolf]

Agree here, maybe we can merge this with manually testing and then address the integration tests with the larger service refactor work?

[markmhendrickson]

Note that I intend to complete manual QA of this PR on Monday, and I've already surfaced one case that doesn't seem to work in this PR atm ("Total balance on home view does not update due to pending outbound BTC transfer", in that in my testing, it does update undesirably).

Other folks are welcome to contribute to this manual QA in the meantime if they want to go through my list and check things off. cc @DeeList @314159265359879

I'm also in support of the larger code changes (that will help mobile as well presumably). @kyranjamie is your sense that these larger efforts will be needed to get this PR finalized, or might we be able to do them in parallel and patch this PR separately in the meantime?

[fbwoolf]

Yep, it looks like in code we filter out pending utxos for both total and available BTC balance, so that needs to be changed before this is merged.

[kyranjamie]

I'm also in support of the larger code changes (that will help mobile as well presumably). @kyranjamie is your sense that these larger efforts will be needed to get this PR finalized, or might we be able to do them in parallel and patch this PR separately in the meantime?

If we can get the main issues fixed here and merged, let's do that. Mostly just making the case that the "real solution" here is a rethink of the solution, and that fixes here are temporary.

[fbwoolf]

I do not see that we ever address availableBalance correctly with sip10 tokens. We seem to only use totalBalance. That change will likely have to be made in the mono repo if needing all the tests listed to pass here.

[markmhendrickson]

I've reviewed more of the balance test cases above and surfaced some that aren't working as expected.

If we suspect these are extant balance behaviors in production, we can get this PR merged and break out the resolution of these cases into its own issue(s) so it's not blocking.

[fbwoolf]

@kyranjamie you might be better to answer ^ question, I'm not really sure what would have existed in production prior to the race to protect/unprotect utxos. I am assuming these were all already in production and can be a separate effort? I don't intend to get back to this until after my swap refactor gets merged. But, if a new issue is created, it can def be assigned to me to do next. Separately, is there a rush to merge the changes here or can they sit?

[markmhendrickson]

I believe this PR incorporates outbound transfers into the available balance shown atop the home view, correct? If so, that seems like the most urgent change in this PR to get live, so it'd be best to merge and release rather than letting sit.

I also assume all of the case-specific balance issues I've highlighted here are also in production already (even if introduced via the UTXO protection work), so here's a new issue to tackle their resolution and test creation separately: https://github.com/leather-io/issues/issues/425