Apply refund to fee bump fee charged

[sisuresh]

Description

Resolves #4188

Checklist

• Reviewed the contributing document
• Rebased on top of master (no merge commits)
• Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
• Compiles
• Ran all tests
• If change impacts performance, include supporting evidence per the performance document

[sisuresh]

This is a kinda hacky, but it does make sure that any adjustment done to the inner fee charged is also applied to the feeBump feeCharged. We could also just expose the refund from mSorobanExtension in TransactionFrame instead, which would be cleaner.

[sisuresh]

Using mSorobanExtension isn't trivial though because there are some cases where the refund is skipped - account doesn't exist or liabilities are too high, so that will also need to be taken into account.

[MonsieurNicolas]

yeah this looks pretty foot gunny:

• inner tx's feeCharged should be 0 in this case (consistent with classic)
• modifying inner tx from the outside like that is brittle

I would recommend refactoring code a bit (maybe add a new virtual function to deal with this)

[sisuresh]

I think we may be mixing up some terminology between mInnerTx's result vs the innerResultPair of the feeBump result here so just to clarify -

1. Are you saying that mResult.result.innerResultPair().result.feeCharged is always 0 in classic? Because that's not true. Here is an example xdr for a payment fee bump where the inner feeCharged isn't 0. And if you're referring to mInnerTx->getResult().feeCharged this also isn't 0 in classic afaict.

2. For your second point, we are not modifying the innerTx's result. We are only modifying the innerResultPair of the feeBump result.

[dmkozh]

r+ 8af4005