test: added few taproot integration test case

[0xEgao]

This PR works on adding the remaining edge cases to test to ensure the Taproot-based Coinswap protocol works effectively and safely under both normal and failure conditions.

Works on issue #658

Already Covered Test Cases

• Two maker single taker swap
• Maker abort after SenderContract from Taker
• Intermediate maker abort after SenderContractFromMaker
• Final maker abort after SenderContractFromMaker
• Incoming contract timelock broadcast before PrivateKeyHandover
• Outgoing contract hashlock broadcast before PrivateKeyHandover

Added in This PR

• Multi maker single taker swap
• Multi taker multi maker swap
• Not enough makers
• Maker abort after AckResponse on SwapDetails
• Maker abort after PrivateKeyHandover by Taker
• Taker abort after AckResponse from Maker
• Taker abort after SenderContract from Taker
• Taker abort after SenderContractFromMaker

[codecov]

Codecov Report

❌ Patch coverage is 96.70330% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.76%. Comparing base (776b75d) to head (36bf352).
⚠️ Report is 71 commits behind head on master.

Files with missing lines	Patch %	Lines
src/bin/taker.rs	0.00%	2 Missing ⚠️
src/taker/api2.rs	98.46%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #649      +/-   ##
==========================================
+ Coverage   68.87%   77.76%   +8.88%     
==========================================
  Files          35       49      +14     
  Lines        4932    15126   +10194     
==========================================
+ Hits         3397    11762    +8365     
- Misses       1535     3364    +1829     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mojoX911]

Overall Ack. Just one major comment for all the test cases.

Instead of asserting for a range (< or >) can we assert for exact values? For all swaps that failed, succeeded, or recovered, the difference between balances should always be a fixed constant number. So we can assert for that number directly, and also mention in a comment why this difference in balance is occurring.

Currently, we are not able to see how much exactly the takers and makers are losing in each scenario.

[0xEgao]

Overall Ack. Just one major comment for all the test cases.

Instead of asserting for a range (< or >) can we assert for exact values? For all swaps that failed, succeeded, or recovered, the difference between balances should always be a fixed constant number. So we can assert for that number directly, and also mention in a comment why this difference in balance is occurring.

Currently, we are not able to see how much exactly the takers and makers are losing in each scenario.

Done

[0xEgao]

Have used assert_in_range macro for maker spendable balance check due to the sporadic cases of +-2sats happening.
No such issues with taker balance check's observed.

[mojoX911]

@0xEgao I think we should also assert for banning behaviors in the taproot tests, just as we do it for V1 tests also.

info!("🚫 Verifying naughty maker gets banned");
    // Maker gets banned for being naughty.
    assert_eq!(
        format!("127.0.0.1:{naughty}"),
        taker.get_bad_makers()[0].address.to_string()
    );

[0xEgao]

Have made the suggested changes i.e. :
1-) Log swap balance for takers
2-) Better balance checks && comments
3-) Mark bad makers
4-) remove saturated_sub

[mojoX911]

@stark-3k can you mark the following TODOs in the tests:

• There are certain fee variances coming for various swaps. Mark a todo to investigate why.
• In case of maker recovery, we are waiting for a timeout. Instead, we should check for the correct log and wait till the maker recovers. This will need some fixes as the current log checking API doesn't handle macOS.

We will turn these todos into issues later, after release. For now this is good to go.

[mojoX911]

Ack