set_code_hash with contract reconstruction

[Zebedeusz]

Fixes #6717

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/12466255018
Failed job name: test-linux-stable-no-try-runtime

[athei]

This is going in the right direction. A few additional remarks:

• When the constructor is trying to set the immutables it will error out because set_immutable_data will make sure it is only run inside of a constructor. However, we are executing the constructor in the current contracts call context (Frame). This code needs some adoption. Maybe a flag inside Frame to signal when we are inside set_code_hash. This also needs to be checked in get_immutable_data to prevent reading immutables inside the constructor.
• The current code will also run into problems when the contract already has some immutable data since we disallow replacing it. Solution: Set contract_info.immutable_data_len to 0 refund the deposit using storage_meter.charge() before calling the constructor. You also need to delete the current imutables from storage before calling the constuctor. Calling set_code_hash will always delete the current immutables which is fine and expected. A constructor doesn't have access to them anyways and is expected to write them if there are any.
• We need to prevent recursive calls into set_code_hash. Otherwise you can trivially consume a lot of memory. Since we are not creating a new frame the stack depth limit is not enforced. I would just generally disallow the usage of this API inside a constructor to address this issue. It seems nonsensical to do that.
• We also need to error out if the current stack depth is at its maximum when calling this API. This is because we are loading a potentially big chunk of code into memory. We are assuming that there are never more than CALL_STACK_DEPTH + 1 codes in memory. This also means that we need to take into account if we are in set_code_hash when doing a sub call. We basically need to adapt this check to add 1 if we are inside set_code_hash.

[athei]

Constructors don't have access to immutables. They set the immutables. Usually by deriving them from the constructor arguments or environment properties (like the caller of the constructor).

So what should be passed here are not immutables but thet arguments to the constructor. In order to do that you need to add a new argument to this function (Vec<u8>) so that the contract calling set_code_hash can provide the chosen constructor with its arguments.

[athei]

Those new error codes don't make sense since we don't check any compat with the old immutables (see other comment).

I think we should add a single new error: SetCodeHashConstructorFailed to signal the error happened within the constructor. All other errors are just bubbled up.

[athei]

This should to be done before calling the constructor. Otherwise it will see the old code hash when querying it.

[Zebedeusz]

@athei
One thing is confusing to me:
"The current code will also run into problems when the contract already has some immutable data since we disallow replacing it." then: "Calling set_code_hash will always delete the current immutables which is fine and expected"
meaning immutables should be replaced but all this time I thought that immutables are part of the contract and not code thus we should only check if the current immutables will work with the code (provided to set_code_hash) and it will be up to the caller to set 1st the right immutables, then the code hash that will work with them.
Is it not feasible or does it just make more sense to do both of these actions in one call?
Then could the immutables be part of the code, since they're replaced alongside it?

[Zebedeusz]

@athei
You also wrote: "When the constructor is trying to set the immutables it will error out because set_immutable_data will make sure it is only run inside of a constructor."
Wouldn't my test fail then? Or is there something different in the way the tests are run that makes it pass but will fail in different circumstances?