Remove `.unwrap()`, even in Tests

[DanGould]

Rust API Guidelines recommend this. It makes for cleaner examples and demonstrates best practice in cases where people copy our code.

I propose all new PRs follow this guideline and we slowly pay back the tech debt of unwrap() in tests.

[DanGould]

Hmm I realized shortly after posting that the API Guidelines are talking about docstring examples or explicit examples, not tests. I still think it's a good idea, but maybe not critical? I also think bubbling up errors is usually not too tricky if the test's signature returns Result<_, Box<dyn std::error::Error>> unless the functions return some funkiness that's not std.

What do you think @spacebear21 ?

[arminsabouri]

Perhaps AnyHow Results could work better in test function signatures. If nothing else the code is more digestable as it replaces all expects(...) and unwraps() with ?.

[DanGould]

Anyhow does make error handling neat, which is why our payjoin-cli and payjoin-directory apps use them as reference.

For the most fundamental docstring tests where Rust API guidelines suggest .unwrap() is inappropriate, I'm inclined to think anyhow suffers from another problem. Instead of being incomplete, like .unwrap(), the example stops being fundamental since it introduces an additional dependency.

For this reason I'm sold on anyhow for our payjoin-cli and payjoin-directory tests and examples where our goal is to demonstrate a neat and sufficiently convenient reference, but I'm not convinced we want to introduce that dependency for our most fundamental tests. .map_err(|e| format!("An error happened in this context: {e}")? will propagate a Box<dyn Error> because both &str and String impl into() Box<std::error::Error + Send + Sync>, which seems more appropriate for those fundamental contexts.

[spacebear21]

If the goal is simply to make cleaner examples that can be copied from our tests, this approach sounds like the best:

bubbling up errors is usually not too tricky if the test's signature returns Result<_, Box>

We can also expose those generic Error/Result types in test_utils to use throughout the codebase and make it available for bindings.