Support updating the node ID on the node contract

[AhmedHanafy725]

This issue is to allow moving the developments across nodes.

• require adding a new extrinsic to the smart contract pallet.
• only allow changing the node within the same farm.
• it can be executed by the owner, the farmer, or the operator (council).
• it might be required to allow changing the deployment hash with it. (leaving it empty means keep it as is).
• execute the billing before moving the contract to the other node.
• this should emit an event to inform the old node that the contract no longer exists to clean up.

[sameh-farouk]

Planned implementation

Extrinsic

migrate_node_contract(
    contract_id: u64,
    node_id: u32,
    deployment_hash: Option<HexHash>,   // None = keep the current hash
)

Origin: 3/5 council (RestrictedOrigin), call index 22.

What it does

Moves a live node contract to another node in the same farm, without cancelling it. The contract keeps its id, its billing state, its reported resources and its reserved public IPs.

It bills the contract first, settling at the source node's rate, and only then re-points it.

It moves the booking, not the bytes

Migration is not live migration.. Nothing is copied between nodes, and nothing on-chain could copy it. This is handled off-chain.

What it refuses

• contracts not in Created state
• a destination in a different farm
• either node opted out of v3 billing, or under a rent contract
• a destination that is in standby, is dedicated, or already holds a contract with the same deployment hash

Two decisions worth flagging

Council-only to start. The driving case is consolidating our own farms: 74 contracts across 29 twins, none of them ours. That is a council action by nature, and limiting v1 this way avoids having to settle who else — owner? farmer? — may move someone else's contract. Owner and farmer paths can be added later as a separate call index, with no storage migration and no transaction_version bump.

No new event — we reuse ContractUpdated. It already carries the whole contract, so it carries the new node id and hash, and the indexer already writes both from the payload. That means no changes in tfchain_graphql or grid proxy. The old node also already cleans itself up, by comparing its local deployments against the chain.

What is still needed, outside this PR

The client has to rebuild the deployment on the destination — and for network workloads, re-peer the overlay.

Traps:

• nodes rejects a deployment whose contract does not already name it.

• Once the contract leaves the source node's ActiveNodeContracts, that node reconciles, finds a deployment the chain no longer lists for it, and deprovisions it — which deletes the disks. Ensure you already pull data off the source disk before it is wiped.

• power-down is gated on ActiveNodeContracts, which empties the moment the extrinsic lands. an emptied node is not safe to power off just because the chain reports no contracts on it.

This reference current ZOS’s logic. Proper handling of these concerns is required from ZOS’s side.