Consolidate HTTP client libraries to reduce complexity

[overcat]

What problem does your feature solve?

Currently, the project is using multiple HTTP client libraries:

• hyper
• ureq
• reqwest

This diversity of HTTP clients may lead to several issues:

• Increased complexity in the codebase
• Potential inconsistencies in how HTTP requests are handled
• Difficulties in maintaining and updating dependencies

What would you like to see?

We should consider consolidating our HTTP client usage to a single library. This would simplify the codebase, reduce potential inconsistencies, and make maintenance easier.

What alternatives are there?

N/A

[leighmcculloch]

Where are the different libraries being used?

[overcat]

Where are the different libraries being used?

The following is the code in the project

ureq:

stellar-cli/cmd/soroban-cli/src/commands/contract/init.rs

Line 22 in c8c3871

use ureq::get;

hyper:

stellar-cli/cmd/soroban-cli/src/commands/snapshot/create.rs

Line 413 in c8c3871

let response = hyper::Client::builder()

reqwest (stellar-ledger):

stellar-cli/cmd/crates/stellar-ledger/tests/utils/emulator_http_transport.rs

Line 7 in c8c3871

use reqwest::{Client as HttpClient, Response};

[leighmcculloch]

Thanks.

hyper is also in use in the stellar/rs-stellar-rpc-client repo (the jsonrpsee http client lib uses hyper) which the cli imports.

reqwest also uses hyper.

[leighmcculloch]

If we were to make a change here, I'd suggest replacing ureq and reqwest with hyper.

[overcat]

If we were to make a change here, I'd suggest replacing ureq and reqwest with hyper.

I saw it written on https://github.com/hyperium/hyper:

If you are looking for a convenient HTTP client, then you may wish to consider reqwest.

If there are no special reasons, using reqwest seems like a good choice. Although it relies on hyper, we won't be using hyper directly in the code.

[leighmcculloch]

That sounds fine too. In which case we could update the ureq case and leave everything else.