Strategy for <TransactionViewComponent>

[grod220]

Currently, the TransactionViewComponent is shared between Prax's tx approval dialog and minifront's tx details page. Reason being, it lives in @penumbra-zone/ui which Prax will eventually have an external dependency on (at the moment, there is a local redundant package fork).

There is an issue though. Prax's tx approval dialog is a security critical portion of code. Having this as an external dep would possibly subject it to changes that do not go through a careful security review.

Options to mitigate:

1. Keep local copy

This would mean keeping a redundant copy of the following:

• TransactionViewComponent
• ActionViewComponent
• And all action components:
  • SpendViewComponent
  • OutputViewComponent
  • SwapViewComponent
  • SwapClaimViewComponent
  • Ics20WithdrawalComponent
  • DelegateComponent
  • UndelegateComponent
  • UndelegateClaimComponent
  • ActionDutchAuctionScheduleViewComponent
  • ActionDutchAuctionEndComponent
  • ActionDutchAuctionWithdrawViewComponent

Perhaps this is not an issue if we expect this to evolve over time different than the tx details page. Though, it would likely mean any changes related to ActionViewComponents will a duplicate PR in two different repos so they both stay updated (example: we add an ActionViewComponent for proposalSubmit)

2. Segment TransactionViewComponent into its own package in penumbra-zone

Being separate would ensure that consumers don't say accidentally update @penumbra-zone/ui and inherit changes in the security-critical component they haven't reviewed yet.

This would mean updates would be strictly opt-in for Prax and would give us a chance to always assess updates.

3. Migrate TransactionViewComponent to prax-wallet org and have minifront depend on prax's implementation

This would ensure the user with the security critical implementation would determine its update schedule.