Reuse HTTP client (and connections) when hitting Charmhub API

[Ben Hoyt]

Currently we create a new HTTP client for (basically) every request to the Charmhub API, so we’re not getting the significant benefit of HTTP connection reuse (keep-alive). This is especially problematic when the latency is high, for example in APAC where we’re a long way from the Charmhub servers (the difference is about 1s per requests vs about 350ms with connection re-use).

We should be able to create a single HTTP client and pass that in as a dependency. Or at least one per facade (eg: one for the client facade, one for the downloader worker, and so on).

However, we need to be careful that changes to HTTP_PROXY (in model-config?) are reflected in a timely fashion. So we need to either monitor for updates to the HTTP_PROXY config var, or in some other way recreate the HTTP client whenever the proxy setting is changes.

Some timing numbers on 2.9 when doing "juju deploy charmed-kubernetes":

* Current: 1m49s best of three (1m57s, 2m0s, 1m49s)
* After my hack to reuse the jujuhttp.Client: 1m18s best of three (1m18s, 1m19s, 1m22s) -- approx 2/3rds of the total time
* With the jujuhttp.Client reuse hack AND async-charm-downloads turned on: 40s best of three (42s, 46s, 40s)

[Ben Hoyt (benhoyt)]

I did this some time ago in https://github.com/juju/juju/pull/14280