Enhance Test Coverage for Receipt Insertion, Batch Processing, and Sender Accounts

[carlosvdr]

This new tests cover are here to enhance the testing experience and help ensure tap V2 wont affect the processes in a "bigger picture"
As well as added more test types around receiving receipts. For this a new method was added regarding batch inserts for receipts into the DB, trying to be have a more accurate representation of how TAP works on a day to day basis.

Regarding the tests on the "bigger picture" , tests for several layers were added.
Such as a full process from sender account all the way from starting it, creating a sender allocation up to the point of marking allocation as last for redeeming.

Another test added from the sender account manager layer which tries to do the same process as the previous layer but starting from the manager.

And finally a test for the full Tap Agent and simulate as closely as possible the full process of it

[coveralls]

Pull Request Test Coverage Report for Build 12835420725

Details

• 239 of 250 (95.6%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.4%) to 78.022%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/tap-agent/src/agent/sender_accounts_manager.rs	47	49	95.92%
crates/tap-agent/src/test.rs	54	56	96.43%
crates/tap-agent/src/agent/sender_account.rs	38	41	92.68%
crates/tap-agent/src/tap_agent_test.rs	93	97	95.88%

Files with Coverage Reduction	New Missed Lines	%
crates/tap-agent/src/agent/sender_account.rs	1	84.41%
crates/watcher/src/lib.rs	4	92.71%

Totals
Change from base Build 12810605983:	0.4%
Covered Lines:	7015
Relevant Lines:	8991

---

💛 - Coveralls

[suchapalaver]

@carlosvdr can you squash/fix the commit history, please 🙏

[suchapalaver]

@carlosvdr , approving just to remove the block 👍

[suchapalaver]

Did you consider implementing this in a "lazy" way since it could be called by multiple tests in parallel and is deterministic? (https://stackoverflow.com/a/59614532/24786256)

[suchapalaver]

I had the same thought about "lazy static" here as well: https://stackoverflow.com/a/59614532/24786256

[suchapalaver]

@carlosvdr this is on the right track but I suggest looking at how others use OnceCell instead of the Mutex. I don't have time to try this myself right now, but I would expect things to look more like:

use lazy_static::lazy_static;
use tokio::sync::{OnceCell, Mutex};
use std::sync::Arc;
use wiremock::{Mock, MockServer, MockGuard, ResponseTemplate};
use wiremock::matchers::{method, body_string_contains};
use serde_json::json;

lazy_static! {
    static ref MOCK_ESCROW_SUBGRAPH: OnceCell<Arc<(MockServer, MockGuard)>> = OnceCell::new();
}

async fn mock_escrow_subgraph() -> Arc<(MockServer, MockGuard)> {
    MOCK_ESCROW_SUBGRAPH
        .get_or_try_init(async {
            let mock_server = MockServer::start().await;
            let mock_guard = mock_server
                .register_as_scoped(
                    Mock::given(method("POST"))
                        .and(body_string_contains("TapTransactions"))
                        .respond_with(ResponseTemplate::new(200).set_body_json(json!({
                            "data": {
                                "transactions": [{
                                    "id": "0x00224ee6ad4ae77b817b4e509dc29d644da9004ad0c44005a7f34481d421256409000000"
                                }]
                            }
                        }))),
                )
                .await;
            Ok::<_, wiremock::Error>(Arc::new((mock_server, mock_guard)))
        })
        .await
        .unwrap()
        .clone()
}

[carlosvdr]

Thanks let me take a look into this