re-enable spend max feature

[TalDerei]

references #1660 and depends on #1801.

to address the feature regression, we implement additional safety checks in both the frontend and services package.

1. The frontend uses checkSendMaxInvariants to determine if certain invariants are satisfied and decide whether to construct the transaction as a Spend or Output transaction planner request. This determines the appropriate planner request that the wasm planner will consume to craft the fully-formed transaction.

2. In the transaction planner service implementation, we've added additional constraint checks in assertSpendMax on the fully-formed transaction. However, these checks occur only after the planning step because, with the current code, there's no effective way to enforce these constraints directly in the wasm planner. This provides a greater degree of validation and safety.

In thinking about this more, while these approaches increase safety, they don't completely cover the entire domain space. There is still an external risk to third-party consumers of our wasm package since we don't enforce these checks directly in the wasm planner. To address this, the final step is to implement the same checks in assertSpendMax directly within the wasm planner. This requires public getters to access the private fields inside the ActionList struct. This is currently implemented in this PR but is blocked until a minor point release is cut on the protocol side.

update – added extra safety checks directly inside the wasm planner.

[changeset-bot]

🦋 Changeset detected

Latest commit: 337b4b9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@penumbra-zone/services	Major
minifront	Minor
@penumbra-zone/wasm	Minor
@penumbra-zone/perspective	Major
@penumbra-zone/query	Major
@penumbra-zone/storage	Major
@penumbra-zone/ui	Patch
node-status	Patch
@repo/tailwind-config	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[TalDerei]

enumerating various test cases manually per #1660 (comment).

The way the logic is structured, if both invariantOne and invariantTwo are false, isSendingMax will be false, crafting an output TPR. However, if either of the invariants is satisfied, a spend TPR will be crafted.

---

0. User sends the non-maximum amount of an alternative fee asset (GM), and pays fees with the native asset (UM).

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

1. User sends the maximum amount of an alternative fee asset (GM), and pays fees with the native asset (UM).

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

---

2. User sends the non-maximum amount of an another asset (Pizza), and pays fees with an alternative fee asset (GN).

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

3. User sends the maximum amount of an another asset (Pizza), and pays fees with an alternative fee asset (GN).

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

---

4. User sends the non-maximum amount of the native asset (UM).

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

5. User sends the maximum amount of the native asset (UM).

invariantOne:  true
invariantTwo:  false
isSendingMax:  true
TPR: spend

invariantOne:  true
invariantTwo:  false
isSendingMax:  true
TPR: spend

---

6. User sends the non-maximum amount of alternative asset (GM), and pays fees with the same alternative asset (GM) since the native token (UM) is absent.

invariantOne:  false
invariantTwo:  false
isSendingMax:  false
TPR: output

7. User sends the maximum amount of alternative asset (GM), and pays fees with the same alternative asset (GM) since the native token (UM) is absent.

invariantOne:  false
invariantTwo:  true
isSendingMax:  true
TPR: spend

invariantOne:  false
invariantTwo:  true
isSendingMax:  true
TPR: spend

---

8. Not able to pay for fees."

[TalDerei]

@Valentine1898 optimistically requested review. I'll implement more comprehensive unit testing and incorporate the additional constraint checks.

[TalDerei]

update

this has taken a backseat in favor of more pressing sync refactoring, but reprioritizing this by adding unit tests that have been sitting in a local branch for some time.

[TalDerei]

waiting for runner to pick up CI job.

@penumbra-zone/web-team please test with sample transactions for extra assurance folks!

[grod220]

issue: Can we split the wasm code off into its own PR? Also, definitely think we need tests for this. See test_planner_delegator_vote.rs as a reference for passing in a mock db.

[TalDerei]

good idea, will open separate PR

[TalDerei]

#1801