pcli: add balance migration command

[aubrika]

initial attempt at implementing a balance migration function for pcli - does not currently handle non-zero fees correctly, but that seems to be the only remaining thing to correctly implement

• If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

  client/planner only changes

[aubrika]

Conor and I confirmed that this implementation seems to work, but only by doubling the estimated fee. Work on this has revealed some issues:

1. The fee estimation logic in the Planner was known to be approximate, but simply doubling the expected fee is an inelegant way to ensure that sufficient funds remain to pay the fees. Can we make this estimation more accurate?

2. The Planner itself is designed such that under its default behavior, it is not possible to easily send a "maximum" amount of the fee token - attempting to send 100% of the fee token will result in a failure, and requires some arithmetic on the part of the user to infer how much can actually be sent. Should we refactor the Planner to perform this calculation automatically, and subtract the fees from the intended amount to send, rather than adding fees to the intended amount to send?

[cronokirby]

I think we want to avoid having to work around the planner, and should instead have a way to express to the planner the desire to send the maximum amount.

[conorsch]

Tested @cronokirby's additions locally, and very satisfied with the results. The source wallet was completely emptied, with no dust notes remaining. The destination wallet received all amounts of all assets, minus the small fee paid to make the transaction. Using the change address was a big missing piece in the first draft of the implementation.

Now, the only concerns I have remaining are:

1. The FVK should be read from stdin, not on the CLI, given that it's sensitive info and shouldn't be memorized in one's shell history forever.
2. It'd be grand to have a functional test for this behavior, but I view that as a nice-to-have.

Regarding 1, I realize we commit the sin of asking for FVK as a CLI opt elsewhere, too, but would like to upgrade the experience to minimize account info dangling in insecure contexts.

[cronokirby]

Tested @cronokirby's additions locally, and very satisfied with the results. The source wallet was completely emptied, with no dust notes remaining. The destination wallet received all amounts of all assets, minus the small fee paid to make the transaction. Using the change address was a big missing piece in the first draft of the implementation.

Now, the only concerns I have remaining are:

1. The FVK should be read from stdin, not on the CLI, given that it's sensitive info and shouldn't be memorized in one's shell history forever.

2. It'd be grand to have a functional test for this behavior, but I view that as a nice-to-have.

Regarding 1, I realize we commit the sin of asking for FVK as a CLI opt elsewhere, too, but would like to upgrade the experience to minimize account info dangling in insecure contexts.

Point 1 addressed.

[conorsch]

Absolutely awesome. The stdin reading prompts interactively for the FVK, and supports reading from pipes, so it's still scriptable, but the FVK won't ever show up as a cli arg in terminal history. Tacked on some nice-to-haves like a custom error message for an empty balance (happens if you try to migrate a second time on the same source wallet), and more verbose help docs. Will clean up the submission text and squash-merge to land.