Rethink gas spending logic

[olonho]

During work on #5121 we identified two questionable places in gas metering.

1. When transaction fails we still require (by tests) that used amount of gas is sum of promised and burnt gas. Seems more natural to zero out promised part.
2. When charging for gas, we always burn the gas even if go the error path. It looks strange and not match with normal paying logic: no operation - no payment.

[matklad]

If we protocol change this, we should also consider changing how we limit promises gas. Rather than checking gas limit on every deduct_gas operation, we can check it once, after wasm execution finishes. Note that we already postpone actual promise creation in the Rust SDK.

[olonho]

It's not hard to keep exact promises gas counter IMO.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[jakmeier]

When transaction fails we still require (by tests) that used amount of gas is sum of promised and burnt gas. Seems more natural to zero out promised part.

I agree in principle with that statement but want to make clear that it doesn't matter, since on an error, we refund prepaid - burnt and the promised gas is not relevant:

nearcore/runtime/runtime/src/lib.rs

Lines 761 to 765 in cd7150e

	let gas_refund = if result.result.is_err() {
	safe_add_gas(prepaid_gas, prepaid_exec_gas)? - result.gas_burnt
	} else {
	safe_add_gas(prepaid_gas, prepaid_exec_gas)? - result.gas_used
	};