Improve Speculative ShieldedContext

[grarco]

#2534 introduces the Speculative context in the client to invalidate masp spent notes so that the client does not end up reusing the same notes when constructing new transactions which would make them invalid. There are a couple of improvements that can be done:

• We could subscribe to the tx and check for its result, if the tx is successful we can commit the local changes to the ShieldedContext, otherwise we can drop them. We could change the name of the Speculative state since this would not be speculative anymore. We need to pay more attention in case of fee unshielding + inner masp tx: in this case the fee unshielding could be successful but the inner could fail and we'd need to commit only the valid part while discarding everything else (Improve speculative shielded ctx #4019)
• Since we don't pre-cache the output notes but just invalidate the spent ones, there's no need to loop on all the viewing keys of the wallet in pre_cache_transaction when calling scan_tx, we could just pass in the viewing key of the transaction source. Actually the key is not even used when calling scan_tx from pre_cache so maybe we can make that arg optional

[cwgoes]

@grarco @sug0 Is this still applicable?

[sug0]

only the first bullet point. the second bullet point has been addressed by #3578

[grarco]

@batconjurer bumping this up seems it looks like the current implementation of the speculative context is annoying people working on the testnets. I believe we should raise the priority of this, or we could also decide to remove the speculative context altogether. It was initially implemented cause the old way of running masp fee payment would have not worked without it and also to reduce the calls to the old version of the shielded-sync command which was less performant than the current one: so maybe there's no real reason to keep it (net for any considerations on shielded sync with the ledger client or the possibility to construct multiple masp inner txs in sequence, which I think should be discouraged since the client could just compact all of them into a single one).

If we decided to remove this context, we should probably go back to silently calling shielded-sync before every masp tx (or balance query) to ease the task from the user perspective.

cc: @sug0