[issues/358] - Capped PVM max gas

[filip-parity]

Limit the PVM per-call gas cap using the runtime’s Normal-class per‑extrinsic weight (BlockWeights minus base_extrinsic) and a storage deposit cap derived from the caller’s free balance minus existential deposit and value sent. The cap is encoded via the runtime’s EthGasEncoder and clamped by the transaction’s gas_limit to align execution with runtime constraints and keep gas reporting accurate.

Motivation

PVM calls were capped using unbounded values, which could exceed Substrate runtime limits and account constraints. This PR aligns the PVM gas cap with the runtime’s per‑extrinsic weight rules and storage deposit requirements to ensure realistic execution limits and consistent gas reporting.

Solution

The max gas capping flow when a contract CREATE or CALL happens in PVM mode:

Step 1: Compute system maximum weight
We read the blockchain's configuration for normal user transactions, get the maximum weight allowed per transaction, and subtract the base overhead cost, the resulting value being the max ceiling.

Step 2: User's gas request validation
We take the user's requested gas limit from their transaction, convert it into Substrate's Weight format where ref_time equals the gas amount and proof_size is set to u64::MAX, then take the minimum between the user request and system allowance.
UPDATE: The system converts requested gas into Substrate weight using runtime calculations, accounts for base extrinsic overhead to prevent block limit violations, scales proof size, and calculates storage deposit caps from actual available balance.

Step 3: Compute available balance for storage
We get the caller's account balance and subtract the minimum balance that must remain (existential deposit) and the value being sent with the transaction, with the leftover value representing the maximum storage deposit they can afford.
UPDATE: improved solution: available = free_balance - existential_deposit - value_sent

Step 4: Execute the contract
We call the revive pallet with the computed weight_limit and storage_deposit_cap from steps 2 and 3.

Step 5: Record actual gas used
After execution, we get the consumed weight and convert it back to gas units using the same ref_time mapping, then clamp this to the transaction gas limit and record it as the gas cost for the transaction.

[smiasojed]

I was thinking rather to use dry-run for gas calculation. I think we should put it on hold as we have again gas changes in pallet-revive with updated gas limits.