Feature request: Show transaction hash for submitted proposals on `SafeMultisigTransactionResponse`

[ubinatus]

Hello Team. Thanks for your efforts on building a game-changer protocol.

Context / issue

Why is this feature needed?

As a developer that builds a Safe DApp and checks on the safe transaction status created by users, would be ideal to know when a multisig transaction has been confirmed by the owner (when threshold is met) but has not been yet mined by the blockchain nor indexed by Safe.

When consuming the /api/v1/multisig-transactions/:safeTxHash/ endpoint, the response is not clear enough when the SafeMultisigTransactionResponse changes from having the required confirmations to having been submitted to the blockchain.

In a nutshell: knowing when the proposal has been sent to the blockchain (transaction hash exists) but has not been mined yet (receipt does not exist). Currently we receive the transaction hash only when the transaction has been indexed by Safe.

Proposed solution

On the /api/v1/multisig-transactions/:safeTxHash/, whenever the proposal has been confirmed by the required threshold and it was executed by one of the owners but the transaction is still in progress (processing), return the transaction hash on the request.

Something so that type SafeMultisigTransactionResponse would be the following case:

type SafeMultisigTransactionResponseProcessing = {
......
  "transactionHash": string, /// <- exists! not null
  "safeTxHash": string,
  "executor": string,
  "isConfirming": true // <- [new] transaction has been confirmed but not mined yet (transaction hash exists but without a receipt)
......
}

Alternatives

Please add a clear and concise description of any alternative solutions or features you have considered.

Since the SafeMultisigTransactionResponse have different statuses and, thus, different outcomes, would be helpful for developers to know the types according to the status. So far, I'm seeing there are 4 statuses through the process of dispatching a successful proposal: i) owner creates the proposal pending to be signed by other owners (CREATED), ii) proposal was signed by the required threshold but has not been executed or submitted to the blockchain (AWAITING_EXECUTION) and iii) proposal was submitted into the blockchain but it has not been mined yet (PROCESSING), iv) proposal was mined and its being indexed by Safe (INDEXING) and v) proposal was successfully mined and indexed (COMPLETE).

Pd: I'm omitting the other cases such as tx failing or proposal being rejected by owners. Would be cool to have those as well.