Receipt::Panic's `contract_id` isn't serialized, resulting in it not being provided by the GraphQL server

[tkporter]

This may be better suited for https://github.com/FuelLabs/fuel-vm (as things are written, the root cause lives there), but this mostly relates to fuel-core functionality so figured I'd open here. I also see by poking through some PRs/issues related to the panic contract_id (https://github.com/FuelLabs/fuel-vm/issues/261, https://github.com/FuelLabs/fuel-vm/issues/256, etc) that the issue I'll describe may be intentional / already known

I initially noticed that the contract_id of a Panic receipt was always set to None when I was hitting a ContractNotInInputs error in some harness tests where I was using fuels-rs. I had previously browsed the vm code and knew that the contract ID should be present to help debug, so I poked around a bit. Adding some logs confirmed that the VM / core logic was accurately setting the Receipt::Panic's contract_id when the tx was executed, but it was getting lost somewhere along the way before fuels-rs was surfacing a response

When fuel-core's GraphQL server serializes receipts, it does so by using the raw_payload function which uses the io::Read impl to serialize to a HexString. The io::Read implementation doesn't set the contract_id, so fuel-core ends up always responding to GraphQL requests with Receipt::Panic raw payloads that don't include the contract id. Then when a GraphQL client tries to deserialize OpaqueReceipts, I believe it'll then use the Receipt io::Write implementation, which similarly doesn't attempt to set the contract_id for a panic receipt

I've confirmed this is the root cause by naively locally changing the io::Read / io::Write impls to read/write the contract_id & changed the SizedBytes impl, but I have a feeling this may have unintended consequences so wanted to open this before suggesting/attempting a specific fix

[Voxelot]

I know that the SDK is currently able to extract the contract_id out of the panic receipts during dry-run execution for estimating what the inputs should be. It will repeatedly simulate the transaction until there are no more contract id or gas limit errors. Maybe the receipt is being serialized differently on dry-run than on the normal tx query.

[xgreenx]

It seems this issue is not actual anymore