Evaluate removal of the speculative shielded context

[grarco]

Follows #4019.

We could consider removing the pre-caching mechanism of the shielded wallet (a.k.a. the speculative shielded context) and go back to calling shielded-sync in the client automatically before any masp-related command (balance query, shielded tx, unshielding tx). The reasons are:

• Poor UX: in general both being in a speculative context or on an old confirmed context leads to a bad experience for the user who could see outdated balances or find themselves unable to produce valid transactions. The current solution based on warning messages and the need to manually call shielded-sync all the times is a bit tedious
• Possible information leaks: being on a speculative (or in general, old state) can leak some information when spending a key
• Performance of the shielded-sync command should be good now and should not be a concern in terms of UX

There's only one possible catch:

• In the docs (https://docs.namada.net/users/fees#masp-fee-payment-gas-limit) we suggest a way to circumvent a limitation when paying fees via the MASP that would require building a batch of masp transactions. This is not currently supported by the client (since we only support batching from the SDK), but if we wanted it we'd need to apply some logic to invalidate spent notes just like we do in the speculative context: this could be done in a separate command though, without the need to have a special type of context that applies to all commands

[grarco]

cc: @sug0, @batconjurer

[grarco]

@sug0 I was thinking of working on this, any objections?

[sug0]

@grarco I think it should be fine to go back to calling shielded sync automatically. Might need to create some namadac config entry to choose which shielded sync client should be used, to avoid having to type --with-indexer every time. At least on a second phase. Initially, it might be fine to keep using the --with-indexer cmdline flag.

Perhaps the SDK should have a flag to avoid syncing or something, idk how namadillo handles its syncing intervals. Either that or we only run shielded sync automatically at the CLI level, and leave the SDK unchanged.

[grarco]

Yeah my thought was to reinsert those calls at the cli level