Clear up estimations around function call costs

[jakmeier]

@matklad @Longarithm @olonho

I think there are several things mixed up in our function call estimations. I will write down my current understanding and we can have a discussion in the comments if anyone thinks I got it wrong.

How we charge a function call

The current cost model for function calls charges the following items:

• Sending and executing the action receipt
  • action_creation_config.function_call_cost
  • (bytes in method name+bytes in arguments) * action_creation_config.function_call_cost_per_byte
• Loading the full contract from the database
  • ext_costs.contract_compile_base
  • bytes in contract * ext_costs.contract_compile_bytes
  • Note that these will be renamed, see protocol_feature_fix_contract_loading_cost tracking issue #5962
• Actual execution cost
  • dynamic costs based on executed code

How we estimate function call costs

The current estimations differs from this model in a few ways.

• ActionFunctionCallBase and ActionFunctionCallPerByte include the loading cost for a test contract
  • This is specifically problematic because it makes the loading cost independent from the size of the actual contract
• The estimation for loading a contract and how it changes with larger contract size are named ActionFunctionCallBaseV2 and ActionFunctionCallPerByteV2
  • This is very confusing because the "bytes" here are from contract size, not argument + method name

Items that need to be fixed

• Adapt ActionFunctionCallBase and ActionFunctionCallPerByte estimations to only cover action creation cost
• [x] Rename ActionFunctionCallBaseV2 and ActionFunctionCallPerByteV2. They already estimate almost exactly what we want to call contract_loading cost once protocol_feature_fix_contract_loading_cost tracking issue #5962 is done.

Edit: Removed references to ext_cost.base, which I just misunderstood.

[jakmeier]

There is also an existing issue around improving correlation between real costs and our estimated costs:: #4826

The issue I created here is not about that. It is about cleaning up existing estimator code. And documenting what we try to estimate. I believe solving this issue can be done separately and will only help to also solve that other issue.

[jakmeier]

Created #6362, mostly to put my code and comment changes around this issue somewhere it doesn't get lost.

Looking at the changes there may also help to understand the problem this issue tracks.

[matklad]

Yup, this all matches my current understanding. I'd fix #5962 before fixing the estimator

[jakmeier]

Done with #6996