fix(api): Improve estimation for gas_per_pubdata_limit

[popzxc]

Fixes the gas_per_pubdata_limit field calculation. Right now, we provide the value we get from deriving the existing batch input, which is most likely lower than limit provided in fee estimation request.
Given that we scale the overall fee, it should be safe to scale the limit as well, as long as we don't go beyond the limit supplied in the tx.

Providing the limit as-is without scaling can be very flaky: transaction risks to be left in the mempool over minor gas_per_pubdata changes.

[slowli]

Dumb question: Do I understand correctly that the changed logic influences zks_estimateFee output only? (There are 2 other uses of gas estimation, eth_estimateGas and zks_estimateL1ToL2Gas, but they both seem to output only Fee.gas_limit.) If so, gas_per_pubdata_limit is overwritten before estimation to a hard-coded value (50,000); is this fine?

zksync-era/core/node/api_server/src/web3/namespaces/zks.rs

Lines 81 to 84 in c156e79

	tx.common_data.fee.max_priority_fee_per_gas = 0u64.into();
	tx.common_data.fee.gas_per_pubdata_limit = U256::from(DEFAULT_L2_TX_GAS_PER_PUBDATA_BYTE);
	self.estimate_fee(tx.into(), block_args, state_override)
	.await

It sort of contradicts "we should not exceed the limit that was provided by the user in the initial request", since the value provided by the user is ignored.

[popzxc]

@slowli

Do I understand correctly that the changed logic influences zks_estimateFee output only?

Yes.

If so, gas_per_pubdata_limit is overwritten before estimation to a hard-coded value (50,000); is this fine?

Huh, that's both fine and not fine. I would expect zks_estimateFee to respect the value if provided, but the reality we're in is that probably nobody actively monitors this value (there is no good tooling and/or documentation for that). So my comment was about the correctness of the implementation, but if we are to discuss the real state of affairs -- it's OK to exceed, since I'm fairly sure that nobody relies on this logic.

[popzxc]

@perekopskiy @slowli do we want to merge this PR, or do you think a bigger rework is mandatory?

[slowli]

I think this PR is fine to merge (AFAIU, it shouldn't break anything), but I won't pretend I'm an expert on the domain, so it's difficult for me to estimate how complete this fix is.