MASP VP refactor

[grarco]

Describe your changes

This PR modifies the masp VP to validate the changed keys in storage instead of validating the Transfer object. It also updates the client to retrieve the data from the changed keys instead of the tx data since this doesn't get validated from the vp. Unfortunately it wasn't possible to completely remove the dependency on Transfer since we still need it for one thing, retrieve the masp Transaction object whose commitment is included in the tx data. Because of this, the masp VP only allows for a single value transfer when a transparent address is involved (whereas the other VPs technically support multiple transfers).

In addition, this PR also makes the operations in the masp VP checked. It has to be noted that operations on I128Sum underneath use check operations even though, in case of an over/under-flow, the application crashes. This solution is more desirable than the default behavior (wrapping around) but in our case it would be better to not crash and just discard the transaction. This type comes from the masp library so either we open an issue there to ask for a better support of checked operations or we rewrite the logic ourselves.

Indicate on which release or other PRs this topic is based on

v0.30.2

Checklist before merging to draft

• I have added a changelog
• Git history is in acceptable state

[cwgoes]

In addition, this PR also makes the operations in the masp VP checked. It has to be noted that operations on I128Sum underneath use check operations even though, in case of an over/under-flow, the application crashes. This solution is more desirable than the default behavior (wrapping around) but in our case it would be better to not crash and just discard the transaction. This type comes from the masp library so either we open an issue there to ask for a better support of checked operations or we rewrite the logic ourselves.

This sounds like a potential DoS vector to me - what if someone crafts a transaction just to cause an over/under-flow and crash the ledger? This may be difficult to do, but it's much better defense-in-depth to just reject the transaction when an over/under-flow happens instead of halting. Perhaps you can ask @murisi for help with the library?