feat: validate coordinator proposed bitcoin fees

[AshtonStephens]

Description

Closes the Bitcoin half of: #1192

This PR is from another PR (#1392) that got split up to separate Bitcoin and Stacks behavior.

This part was separated from the Stacks half because there's an issue with the way the transaction will be represented in the Signer database when a transaction is marked as invalid based on the coordinator's proposed fee:

@djordon
The only trouble with this is that it's not clear why the the transaction is invalid when looking at the data in the signers' database. I wonder if we should do something else here instead. Maybe we could change the result for the signers' UTXO to be something other than Ok when the fee is too high?

Changes

• Adds logic to bitcoin transaction validation that considers a transaction to be invalid if the fee on it is more than 5 times plus 5 satoshis greater than the Signer estimates it should cost.
• Adds unit tests and integration tests

Testing Information

unit and integration tests

Checklist:

• I have performed a self-review of my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[AshtonStephens]

Existing comments on this code can be found in the original PR of which this is half:

• Add configurable max stx fee and avoid signing Bitcoin transactions with absurd fees #1392

[cylewitruk]

Could you create an issue and add it to the TODO? I think it sounds reasonable to have a sanity check..

[cylewitruk]

So I remember there being a discussion about config vs. not and landing in that these shouldn't be exposed as config. What's the thinking around having config for Stacks max transaction fee but not these parameters?

[cylewitruk]

Hm, I'm not really following why this is &mut and then you're clearing it at the end? Is it that you only want this to be provided for the first transaction in the event of chained utxo's in mempool? If so then I would probably change the for loop above to use .enumerate() and only provide this on the first iteration instead of doing this dance.