Support tenderly sim for end-state of the queue tx in timelock

[petrovska-petro]

          the ui is def a great addition, something that came to my mind that will be valuable to support is that when queuing a tx in the timelock to have a better scope of what storage variables may affect or what modifications represents, would be worth to have a tenderly simulation url to share w/ the rest of potential signers? 

wdyt of adding that feature in the flow while either queuing and/or executing so it prints out on the cli?

so early queuing of txs will allow quick inspection of what result will be resulting when finally executing after the delay*

_Originally posted by @petrovska-petro in https://github.com/ebtc-protocol/ebtc-multisig/pull/3#discussion_r1446765230_

[sajanrajdev]

Great idea. We should add it to the sprint for before launch but with lower prio than other core features as the Safe UI already incorporates simulation.

My only suggestion is to add a Tenderly sim to all transactions (timelocked or not) in the same way that we do in the Badger Multisig repo. No harm and could benefit the review of txs outside of paramter changes.

[petrovska-petro]

the case im suggesting its not the simulation when queuing, which i agree already is supported by the safe ui when its going to be signed

what it is not supported by the safe ui currently afaik, its to provide the simulation of the state of the tx which is queued and going to be exec, what states will be changing in the architecture, that's what i think it's a valuable addition

i.e:

• provide the sim of the after state of the tx which is just going to be queued, providing awareness of what results will have in the system

not having this the current situation is something like this:

• i can sim the queue tx and perhaps its correct signatures, targets, deadline, but what im signing now in what will result after the delay?

wdyt?

[sajanrajdev]

@petrovska-petro, I think it makes sense to show the simulation of the transaction for when it executes indeed. Perhaps it can be an option that gets automatically toggled when the script runs the queuing route but that it can manually disabled in case we want to simulate the queuing itself for whatever reason. For the rest of the operations, let's make sure that we can also simulate (i.e. treasury ops, etc..).