Partial fee estimates for SubmittableExtrinsic

[tadeohepperle]

Partially fixes #527.

There are two rpc endpoints that can be used in principle to obtain an estimate of the partial_fee. That is the paid fee without tips. I added a function partial_fee_estimate() to SubmittableExtrinsic, that uses Method I, as it is simpler.

Method I: TransactionPaymentApi_query_info

The struct RuntimeDispatchInfo returned by this endpoint contains a the partial_fee in question:

let encoded_with_len = self.encoded_with_len();
let RuntimeDispatchInfo{ partial_fee, ..} = self.client
 .rpc()
 .state_call_decoded::<RuntimeDispatchInfo>(
     "TransactionPaymentApi_query_info",
     Some(&encoded_with_len),
     None,
).await?;

Here the partial_fee is already the result we are looking f

Method II: TransactionPaymentApi_query_fee_details

Make a state call to "TransactionPaymentApi_query_fee_details

let encoded_with_len = self.encoded_with_len();
let InclusionFee {
    base_fee,
    len_fee,
    adjusted_weight_fee,
} = self.client.rpc().state_call_decoded::<FeeDetails>(
    "TransactionPaymentApi_query_fee_details",
    Some(&encoded_with_len),
    None,
).await?.inclusion_fee.unwrap();
let partial_fee_2 = base_fee + len_fee + adjusted_weight_fee;

Referring to this this stackexchange answer by jsdw:

partial_fee = base_fee + len_fee + (adjusted_weight_fee/estimated_weight*actual_weight)

We assume here, that estimated_weight == actual_weight.
So this should hold and give the same result as Method I:

partial_fee = base_fee + len_fee + adjusted_weight_fee

Tests:

I added an integration test that verifies both methods work and return the same result.

[lexnv]

I do wonder if we could use the exposed state_call under our rpc.rs methods.
Generally, we can avoid making plain rpc requests and rely on the exposed functionality of the rpc.rs.

This has the following advantages:

• no need to remember and hardcode the function name.
  Placing static str in the code base can be limited to the rpc wrappers, which results in better code maintenance. We also get better error handling. Making a call to rpc.state_cccall() is a compile error while calling "state_cccall" will be detected at runtime
• Parameters are defined in the function signature, which hints at the values we'd need to pass in. On the other hand the rpc_params can take in any parameters (potentially incomplete).

Let me know what you think of it 🙏

[jsdw]

Yeah; let's just make the result of this call_raw be Res: Decode :)

[tadeohepperle]

@lexnv Good idea. Should I change something in the code now, or is that a thing for another PR?
@jsdw I would like to make your suggested change. But the function name should stay call_raw? So the raw then only refers to the call_parameters: Option<&'a [u8]> and not to the return type anymore, right?

[jsdw]

Yeah, keep the call_raw; this is because in the future we'll be adding a much more ergonomic call method which will be the preferred way to use this interface :)

And please feel free to make the change in this PR so that we can keep the code simple given the definition of the state_call RPC method!

[niklasad1]

LGTM, nice work

[niklasad1]

I wonder if it's sufficient to just rely on that the result from Method I: TransactionPaymentApi_query_info could be decoded as this should already be tested by substrate I reckon.

Then remove this extra code 👇, but this is a nice way to check the result so I have mixed feelings here your call

[jsdw]

I'm happy either way too; I don't think we need the test but it's interesting in documenting how the things work so I'm easy :)

[tadeohepperle]

If the logic changes in the future the test will break, then we can still change/remove it I think :)

[jsdw]

Nice; more compact code with nice comment to explain :)

[jsdw]

Looks good to me; nice job!