Our dependency is twofold, in function arguments and in errors. We can more easily maintain stability of our public API if we internalize our url dependencies in both function arguments and in error variants.

Using url::Url in the public API may be a form of tech debt, in that we took it on to get the API out without full consideration at the time the dep was first introduced by Kixunil.

Don't' depend on url::Url in function arguments

Instead, take Url arguments as IntoUrl trait implementations in core typestate machine instead of url::Url.

We have to re-export url::Url, bind to it, and have downstream implementers manually parse URLs before payjoin will accept them as arguments to many functions that produce requests e.g. Sender::extract_v2.

Instead, an IntoUrl trait like reqwest over &'a str, &'a String, String that handles Url validation inside the typestate machine would abstract this burden from an end user and make one less error for them to handle since it'd be encapsulated in our variants resulting from those extract or setup functions.

related: #459

Don't depend on url in public error variants.

We have no explicit url::ParseError variants in our Error types because they're only internal variants, but if we were to make those variants public we would. We also make downstream users construct their own Urls to pass to our functions which makes them handle the ParseError on their own rather than encapsulating that logic and error handling in our extract_ functions or similar.

related: #403