feat(contracts): add tx_id to FuelCallResponse

[Br1ght0ne]

Description of changes

Close #733.

• for scripts, tx_id is Transaction::Script.id()
• for contract calls, tx_id is ExecutableFuelCall.tx.id()

Checklist

• I have linked to any relevant issues.
• I have updated the documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary labels.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[digorithm]

Short and neat. gg!

Just gotta fix the tests, but after that feel free to merge!

[digorithm]

Changing my review until the test gets fixed to prevent an accidental merge haha.

[iqdecay]

Just one question regarding async.

[iqdecay]

So I like that we don't need to call the network to get the tx_id, but I do agree with the comment about changing the get_response API.
First of all this is afaiu a breaking change that we should consider carefully.
Second, I agree with you that it is wonky.
I'd like to see what a caching solution looks like 😄

Can't we include an extra Receipts type that just gives us the txid? But it would feel bad to "lie" about it being a tx receipt.

EDIT: @digorithm can you weigh in on priority vs (having an async || changing the API)?

[digorithm]

Hmm, seems like we're bound to modify the API, regardless of the options. Having to append .await is a change to its API, anyway.

Are we deciding between let response = call_handler.get_response(receipts).await?; and let response = call_handler.get_response(receipts, executable_call.tx.id())?;?

If so, the first option doesn't require the user to know more internal details and manually fetch the tx id, which I believe to be better than the second option.

[iqdecay]

Agreed but I feel like Br1ght0ne is hinting that he maybe has a solution that isn't async and doesn't need the user to know the tx_id.
My question was: is it too urgent for us to wait on the implementation which seems tricky? Or can we wait a bit.

[iqdecay]

LGTM, but please add documentation and tests

[iqdecay]

nice

[iqdecay]

Lgtm

Everything is implemented :)