Updated prefix reservation

If you toggle Send Confirmations in config to true, then send a normal XEC tx, that setting resets to false after tx broadcast.

Edge case: Send a token tx where you're sending the entire remaining token balance so that it needs to automatically route out of the SendToken.js and back to Home. The following bad state use warning is shown:

So my steps were:

1. Deploy v2.0.10 to netlify
2. Create new wallet on there
3. Bump version to v2.0.11, then redeploy to netlify
4. Waited around with the wallet open but no modal.
5. Closed and re-opened browser, upgrade modal shows up on load
6. Click OK, cashtab refreshes but Configure.js is still showing v2.0.10
7. Hard refresh browser, cashtab now shows v2.0.11

Updated wed/extension logos and wording.

Manual testing observations:

• When switched to another wallet, the wallets[0] is updated but the separate wallet object is still on the previous wallet. Deleting this stale wallet in the wallet object does not update it.
• Even with this mammoth refactor, wallet cache did not nuke.
• No longer seeing that edge case where clicking Activate on another wallet loops back to the same wallet, until you click Activate a 2nd time
• Wallet switching is soooo much faster now

Error: Cannot find module '../../mock-chronik-client/mocks/mockChronikResponses'
Require stack:

• /work/apps/examples/test/sendXec.test.js

Just so I'm clear on the underlying use case here, will this be used to parse through all tx history of the address to figure out whether the address has received this token at least once in its entire history, or is it to determine the user is currently holding a balance of this tokenId? If it's the latter then you can just use the etoken-list lib can't you?

accepted with note

I assume txs like this self minting tx are out of scope for this token server right? The function will return false as the minter won't be in the inputs but I guess this wouldn't be generated out of cashtab anyway yea?

1. I can see the reasoning for getting rid of token ID is because it's not in chronik-client's genesisInfo, but why are the other properties grouped together in index [1]? Isn't it simpler to have them as individual props? Is there a performance/caching consideration here?

👍🏼

version bump and rebase

lint fix

Updated pagesize to 20

rebase

@bot cashtab-tests

Updated txhistorycount to 20