New RPC: z_getnewaccount

[str4d]

• Selects the next available sequential account number under the UA-compatible HD seed phrase and persists account metadata to the wallet.
  • This enables rescanning to find all accounts.
• Generates the corresponding spend authorities for the best and second-best shielded pools, and the transparent pool.
• Returns JSON dict with e.g. the account number (u31) and the default / first UA (containing the default addresses for each pool).
• Does not return account 2³¹ - 1 (see ZIP 316: Document standard key structure for Unified Addresses zips#511).

[nuttycom]

Notes from a discussion in Slack:

I think that this RPC method should not return the default address. There are a few reasons for this:

First, we would like to encourage our users to avoid reuse of unified addresses that contain transparent components. Ideally, we'd like our users to migrate their workflows to be account-centric rather than address-centric, and separating address generation from account generation helps with this.

Secondly, accounts are not associated with a specific set of receivers; instead, selection of receiver types is performed only at address generation, and inside of zcashd the internal USK and UFVK for every account support all implemented receiver types. This is important for forward compatibility: we only want the UFVK to be cached in memory; we don't want it to persist with a subset of the possible item types. The same is true of the USK; we want to regenerate it from the mnemonic seed for the account as needed. That way, when we add future protocols there's essentially nothing that needs to be updated in the wallet's data store, because we don't store anything that needs to be updated!

When you look up the UFVKId for a given receiver, you get enough information to reproduce the address you generated from which that receiver was extracted, as it was at the time it was generated. The UFVKId will change when we add a new pool, and newly created addresses will map their receivers to the new UFVKId. Importantly, multiple UFVKIds can map to the same logical UFVK, so the metadata of newly generated addresses will refer to the "updated" UFVKId.

[str4d]

I'm not sure I agree with all of the above. However, it's easy to add new fields to this RPC later, so I'm okay with requiring users to make a second RPC call for now, and then if it becomes a clear UX misstep then we can add the output again.

[str4d]

Closed by #5475, merged into #5419.