Agama cli to be able to use different api urls

[mchf]

Problem

We want to be able to use different remote installation servers

Solution

• Introduced global option for user to provide remote api url
• Used newly introduced BaseHTTPClient to handle urls.

Already done:

• auth, network, localization, users

Testing

• Tested manually

[mvidner]

I have tried this out, with this testing setup:

• Run agama in a container, with /testing_using_container.sh; this builds the Rust code in rust/target/debug, and exposes port 443 to 10443 on the host
• (Now I wanted to simply run the agama binary on the host, but this fails for me because 15.4 is too old and misses the new glibc and openssl that the TW container is using)
• Compile agama in release mode on the host, cargo build -r which puts the binaries to rust/target/release

Now I can try rust/target/release/agama --api https://localhost:10443/api auth login

But it does not work yet:

1. there seems to be a funny bug: BaseHTTPClient always wants an authentication token from a file, or else it fails (NotAuthenticated is printed). I needed to mkdir -p $HOME/.local/agama; touch $HOME/.local/agama/token
2. the --api option seems to be ignored:

$ ./target/release/agama --uri https://ohmu:10443/api auth login
> Please enter the root password: ********
Anyhow(error sending request for url (http://localhost/api/auth): error trying to connect: tcp connect error: Connection refused (os error 111)

[coveralls]

coverage: 70.979%. remained the same
when pulling 1d7d84c on api-option
into ce0c770 on master.

[mvidner]

With #1438 being merged, this PR could be extended to work with agama config load, because this CLI command will ignore the parts of the API that are left unspecified in the JSON, and we can test only on the user, root and localization parts, that already have HTTP clients

[mvidner]

Also note that in #1438 I needed to connect to a mock HTTP server and made client APIs for that, which should be pretty useful for your use case too :)

[mvidner]

The current code looks good but the auth endpoint is special and IMHO we need to see how this works with a regular one too.