Bump ureq to 3.0.0

[sosthene-nitrokey]

This would be a breaking change. Benefits: some of the feature we needed to improve the reliability of the pkcs11 module were only available in our fork. This would allow us to use the upstream version.

[robin-nitrokey]

And it would also make the TLS configuration for the tests much easier, so I’m in favor of updating.

[sosthene-nitrokey]

No it would not, on the opposite it would make it more complex. This currently fails because when disabling TLS it says to the server that it does not support any Signature scheme which leads to an error :(

And in the pkcs11 module we would still need some custom TLS config. But at least now it will not depend on a semver hazard.

[robin-nitrokey]

AFAIS the custom Verifier in the tests can now be removed (and maybe even the rustls dependency?). And do we still need to pin the ureq dev dependency to a specific version?

[robin-nitrokey]

Please add a changelog entry before merging.

[robin-nitrokey]

I wonder if it would make sense to implement the operations in terms of the http crate instead of using ureq directly. This would allow us to make ureq optional and ureq updates would no longer be breaking changes. We could of course still provide a default implementation using ureq.

http is also supported by hyper and reqwest so we would cover all major Rust HTTP clients.

We could either let the user provide something like a Fn(http::Request) -> Result<http::Response, Box<dyn Error>> as part of the Configuration. Or provide structs that can be converted to and from the http types to implement the operations – that would even be compatible with async HTTP clients.

[sosthene-nitrokey]

That could sound good (or we could also use an async-trait and a normal trait for the sync client and have implementations for both).

I'm not sure it's worth implementing without downstream requests for it.