Add wallet/setAccountHead RPC

[dguenther]

Summary

Implements an RPC for manually updating an account's head. The user can pass in hashes of transactions known to be owned by the account, and the wallet will decrypt and apply only those transactions to the account's state.

Needs Review

• Should the name of the RPC route be different? Renamed from wallet/addKnownTransactions to wallet/setAccountHead
• Should this logic live somewhere other than an RPC route, e.g. integrated with the wallet? We might move this out into the Scanner once it's refactored out of the wallet.
• Should the route have wallet context instead of fullnode? Decided this is fine for now since it's similar to a service command anyway.
• What should we do if someone cancels an RPC request before updateHead finishes? Added early-exit to the loops by checking request.closed.

Testing Plan

Added automated tests for the RPC.

Manual testing

1. Run wallet:scanning:off to disable scanning for an account
2. Run wallet:transactions on the account. Save all transaction hashes.
3. Run wallet:status. Save the account's head hash as end
4. Run wallet:rescan to reset the account (Add wallet/resetAccount RPC #4985 will allow you to do this for one account). Cancel the scan
5. Run wallet:status again. Save the account's head hash as start
6. Run start on the directory.
7. In a separate prompt, run repl on the directory. Execute the command with the values you previously saved.

client = await sdk.connectRpc()
(await client.wallet.addKnownTransactions({ account: "account", start: "startHash", end: "endHash", transactions: [{ hash: "ceddfc8c0978db964f8fb3ad66f4d127235dcd25385401e2cd092a7c088c8992" }] })).content

After running wallet:status again, you should see the account restored to its former state.

Documentation

Does this change require any updates to the Iron Fish Docs (ex. the RPC API
Reference)? If yes, link a
related documentation pull request for the website.

[x] Yes

iron-fish/website#706

Breaking Change

Is this a breaking change? If yes, add notes below on why this is breaking and label it with breaking-change-rpc or breaking-change-sdk.

[ ] Yes

[NullSoldier]

This PR looks extremely well written to me. The tests are very easy to verify. My only comment here would be, we should abort eagerly when we can if the request is closed so we don't continue using up CPU if the client disconnects. Especially because we don't have an account lock. It'll prevent the client re-trying the request and causing havoc if they disconnect.

[dguenther]

I added early-exit to both of the loops. Tested it by curling wallet/addKnownTransactions with start at block 1 and an account with head at block 500k, then closed the request after a few seconds. Verified that the account head was no longer rolling back to block 1.