Fix feerate calculation

[lontivero]

Fixes #9323 and removes fee rate tolerance workaround. This PR takes into account the shared overhead for estimated size and effective fee rate depending on whether the coordinator pays for it or not.

Update:

Look, a bitcoin transaction has inputs, outputs and 58 bytes that are common (version, locktime, two 3 byte varints are non-witness data, marker and flags are witness data).
Clients pay the specified fee rate for their inputs and outputs however nobody is paying for the common parts. That means that if the fee rate is 100sats/B and you register one input (69bytes) and one output (31bytes) you have to pay 100 sats, because the fee rate is 100 sats/B and you have registered 100 bytes. However the transactions is 158 bytes and that means that you didn't pay the correct fee rate (100 sats/bytes) but a much lower fee (63.29 sats/byte)

For that reason the guard condition EffectiveFeeRate < Parameters.MiningFeeRate started to fail when the mining fee rate went up and the number of inputs/outputs went down. In other words: it was working just by pure chance.

[molnard]

cACK, see my review here #9566

And one more, the coordinator and the blame script are the same. So we are paying that fee twice.

[molnard]

ACK