Handle IBC deposits/withdraws to/from payment addresses

[sug0]

Describe your changes

Closes #4830
Closes #4168

Allow IBC deposits into payment addresses (without generating MASP transactions), and IBC withdraws from payment addresses (to automatically get refunded, if an IBC unshielding transfer fails on the counter-party).

These changes should substantially improve the UX of MASP over IBC.

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies: Parse MASP events from protocol shieldings namada-masp-indexer#111

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for ed70e61.

🟢 All jobs passed!

But CI Insights is watching 👀

[sug0]

oops, I broke something between the last two f-pushes

[murisi]

Thanks for clarifying the context of this code. I see nothing obviously wrong or improvable with the changes to the MASP VP or the transfer context. I just wonder if we could utilize existing code and execution paths more in order to minimize risk. For instance, the transfer context has code to update the note commitment tree and the undated balances though apply_shielded_transfer does something similar. In the MASP VP, the new logic skips the anchor check execution paths when the ProtocolIbcShielding condition is met.

I guess I just wonder if there could be a single function to create a dummy transaction based off (owner_pa, token, amount, ...) (potentially having correct anchors) that can be:

• constructed (from the event) and used by clients to update their shielded state
• constructed and used by the transfer context to update undated balances and note commitment tree (somehow using the apply_shielded_transfer function)
• constructed by the MASP VP (from the event) and fed into the existing verification logic in a way that minimizes the number of checks that are disabled/the number of paths through the verification logic.

A unified dummy transaction logic would ensure that IBC transactions are synchronized, executed, and verified in the exactly same way. Overall the code is likely correct, but it would be nice to leverage existing mainnet code as much as possible to minimize risk of unexpected behaviour. Of course, this hypothetical approach might not be practical!